Re: <insert> and external entity references

Murray said:
                                                       
> This would really be the big change: not using HTML as the base 
> language of the Web. We'd use SGML (MIME type "text/sgml; 
> level=1|2|3|4"), allowing > the DOCTYPE of the document to 
> determine the DTD, just as in SGML. That DOCTYPE could simply 
> specify a dialect of HTML for the current majority of web documents.

Abigail replied:

> I have heard this many times, yet I see problems noone has given
> me an answer to. HTML certainly is more than just a grammer.
> Search engines can index a document properly _because_ there
> is an implicit meaning to <TITLE>, that <H1> is more important
> than <H6>, that <STRONG> is used for something else than <B>, etc.

Murray counter-replied:

> Concerns over TITLE, ISINDEX, etc. are met with the application 
> conventions of whatever SGML application we're dealing with. I'm 
> not of the mind that there will be a dozen different SGML 
> applications floating out on the web, unrelated to HTML. There will 
> probably be very few, with a multitude of variants upon a central 
> referent. That referent application will be some evolutionary 
> descendent of current day HTML, and will inherit many of the 
> application conventions of HTML.

I am concerned about defining a standard for "SGML on the Web" that
does not allow me to publish _any_ of my existing SGML documents (with 
changes only to the entity references). If this means that we have to 
wait for super-powerful style sheets then I say wait!!  What you are 
defining is just "flexible HTML" and is very close to Dan's "platform 
for experimentation in HTML." I think that this "flexible HTML" is very 
important, but it isn't SGML on the Web.

I should not have to design my DTDs to be "web compliant." The web 
should learn how to work with my DTD! This is what Java/Active-X/Plug-Ins 
are all about, right? Keeping your data in the most natural format by 
creating a more flexible client. Shouldn't we be approaching this by 
asking: "How can we get these TEI, CALS, and DocBook documents to work 
right on the Web"?

We could do this by defining a sufficiently powerful style sheet
language (or set of languages) to interface between the various SGML 
documents and all of the major "processing applications" that manipulate 
Web documents. Here are some things that HTML tools do "for free" that I
think we might have to make style sheet languages for:

Online Display (fonts, colours, layout)
Print Display (fonts, colours, layout)
Audio (volume, intonation, breaks)
Search engines (they need to know what tags represent 'keywords', 
                'title', 'heading', etc.)
Source Pretty Printing (fonts, colours)
Forms (what does your CHECKBOX element do? is it the same as INPUT in 
       HTML?)
Tables (what table model? What elements?)
Table of Contents (what elements should I list in one?)
Index (what elements should I list in one?)
Other navigational tools (Panorama has a concept of a "navigator")
References (how do they look?)
External references and links (what syntax does the DTD use? HTML? 
                              HyTime?)
Inter-document relationships (what elements or attributes correspond to
                             HTML's LINK and REL/REV?)
Other Meta-data (how do I figure out who is the author? the last 
                edit date?)

Yes, we could define a style sheet language, or style sheet languages that
support all of these concepts. But we haven't done that yet, and I haven't
heard of any IETF or W3C mailing list where they are being discussed. 
Is there one? Shouldn't there be?

Sure I can make Panorama style sheets for my existing SGML documents, but
the resulting "system" will be less functional in some ways than an HTML
based system (and more functional in others). And my style sheets will 
probably be totally useless in other "SGML tools." Panorma's style sheet
format is not standardized. The navigators are not standardized, and 
certain features only work with particular DTDs.

 Paul Prescod

Received on Wednesday, 20 March 1996 07:28:10 UTC