Re: HTML should not be a file format, but an output format

At 10:11 AM 3/23/97 -0800, Terje Norderhaug wrote:
>Phrases like "tagging content in SGML" has a meaning that may not be
>obvious for those not familiar with SGML and its philosophy. May be it is
>timely to clear up discussions by specifying what is implied and assumed so
>that those new to SGML get an understanding of what this is all about.

Thanks for clarifying this for us ;) 

I've been using SGML since 1993, when the document conversion company
I worked for started doing technical manuals (IETMs and otherwise) and
other conversion work for aerospace and military clients. It has
always bothered me that since HTML became so huge everyone outside of
the SGML community has considered HTML and SGML as two types of the
same thing, rather than saying "HTML/3.0" vs. "IDDOC/1.0" vs. 
"GASTURB/2.1" DTDs, etc. 

I agree in spirit with your remarks about SGML as being more than a
metalanguage for defining document types and their instances. However, I
think that your assumption is that HTML cannot be considered a valid SGML
application according to your view. Just because most HTML authors are
not as stringent WRT the use of validating parsers, embedded formatting
instructions, and so forth does not make "true" SGML applications free
of such slackness. It does not forbid HTML authors from producing good
SGML-compliant documents, either. 

When we were producing SGML for IETMs the tagsets were highly specialized
WRT the application which would eventually display the TM. This included
many features such as menu item accelerators (using the &File construct
under MSWindows for associating keybd accelerators) for example, which 
were far from the ideal "separate structure from content from formatting"
manta which SGML advocates are always preaching. I, too, agree with the
general ideals behind SGML, but practical matters always rear their ugly
head and limit the ideal nature of the actual product. Timeframes and
other icky manifestations of reality kept us from producing the long
sought after "ideal SGML document" and filters which would produce the 
dirty, foul, earth-bound, specific implementations with all their 
impurities, embedded formatting and processing instructions, etc.

SGML is like eastern conceptions of the Godhead - when SGML is instantiated
in a given application, it is not true SGML. Although it may borrow power
from its origins, it is always limited by the nature of the body it has
chosen to inhabit ;^) Such is the way of ideal vs. real.

I repeat, for clarity, there is no such thing as an SGML document. There
are only instances of documents which have been marked up with an SGML
compliant tagset. You make the point that SGML environments are more
stringent and more flexible at the same time, due to their adherence to
certain unspoken guidelines regarding the use to which the tags are put,
the means by which they are validated, and the degree to which they
do not profane themselves through imperfect realizations of SGML dogma.

I miss these religious wars ;^) My life has been somewhat cheaper and
more empty since I stopped reading comp.text.sgml...

Steve


--
Steven Champeon                  !        I'll sleep
Web Guru/Intranet Builder        !       when I'm dead.
schampeo@hesketh.com             !         - Zevon

Received on Sunday, 23 March 1997 13:45:24 UTC