W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > November 1996

Re: Recent ERB votes

From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Date: Fri, 08 Nov 1996 12:11:13 -0500
Message-Id: <1.5.4.32.19961108171113.009ec188@csclub.uwaterloo.ca>
To: W3C-SGML-WG@w3.org
At 11:15 AM 11/8/96 EST, lee@sq.com wrote:
>Paul Prescod <papresco@calum.csclub.uwaterloo.ca> wrote:
>(1) the entire bible is only approx. 5 MBytes -- not exactly a large
>    database.  (I don't mean to denigrate what Jon did, by the way, but
>    it pales to insignificance in terms of size when compared to the
>    Novell online documentation, for example)
>
>(2) It's accessible today in Panorama; whether you call Panorama complex or
>    not may depend on how much of the source you've seen :-) but it's
>    certainly affordable!

Sure. But what if Jon wants to publish those to his Bible Study Group? Or
publish his Shakespeare collection to his Shakespeare scholar's collection
group? Do we expect them all to download Panorama? What about those that are
using terminals in libraries, or other people's computers?

If 
 a)Panorama were a standard part of Netscape or IE, 
 b)it had display mechanisms were based on standards (i.e. DSSSL-O), 
 c)it had performance on par with regular web browsers, 

then XML would be irrelevant. Simple SGML would still be important, but that
would be an ISO project, not a W3C one. XML should be ubiquitous (and thus
simple), standards-based, and fast (and thus simple).

>> If we could
>> easily create print and online versions of annual reports, manuals, etc., we
>> _would_ be able to attract people and programmers who do not today use SGML.
>
>I agree.  Of course, empty elements aren't related to that.
>And neither is downloading SGML databases over the internet...

They are related to that, through simplicity. If we can make parsing
simpler, we will get better browser support, and thus ubiquity. We will also
get better performance.

>> Again, the goal isn't to support HTML "du jour", but provide a smooth
>> migration path from HTML to XML for the short term.
>
>Then why wire in a list of HTML "du jour" EMPTY elements into
>XML perpetuity?  The same program that converts today's HTML into XML
>can change <BR> to <BR/> if it likes.

Because the ERB is _!NOT!_ interested in compatibility with HTML _documents_
but with EXISTING HTML BROWSERS! They want to be able to do this, in the
short term:

<P>This is an <ABBREV>HTML-like</ABBREV> document with <ABBREV>TEI<ABBREV>
style <gi>date</gi> elements, written on <date value='1980-02-21'>21 Feb
1980</date>. It also has a <ABBREV>TEI<ABBREV> header (though it is not
shown here). Thanks to the magic of <ABBREV>CSS</ABBREV> style sheets, and
<ABBREV>HTML</ABBREV> convention, the <ABBREV>TEI</ABBREV> tags can either
disappear, or be mapped to special formatting for existing browsers.

 Paul Prescod
---
Boycott Shell Oil worldwide!  http://www.web.apc.org/embargo/shell.htm    

"Shell is here on trial and it is as well that it is represented by counsel
said to be holding a watching brief."..."The ecological war that the Company
has waged in the Delta will be called to question sooner than later." -Ken
Saro-Wiwa to the tribunal that later executed him.
http://www.goldmanprize.org/goldman/ken.html
Received on Friday, 8 November 1996 12:09:29 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:03:42 EDT