Acceptance of XML
I've been following the discussion on the various topics and am concerned that
in dealing with interesting details, we are ignoring the even more interesting
"big issue" - accpetance.
SGML is an important international standard, has garnered wide support, and is
required for many applications. The flexibility inherent in SGML makes it ideal
for a class of applications that cannot be supported by lesser markup languages.
HTML is an obvious lesser language. SGML is superior and I support it.
HTML, brain-damaged though it may be, has in short order dramatically eclipsed
SGML in terms of number of adoptees/users. Functionality has improved to the
point that some (none on this list) believe that HTML is, or will be the
one-size-fits-all document markup. Clearly this is not the case and HTML is
bound to "hit the wall" - in fact it already has on several occasions.
Left to their own devices, HTML hackers (perjorative term) will invent new
markup to solve specific problems/limitations with the then current HTML
standard. Eventually, someone in the "HTML community" will realize that an
elegant (and not especially difficult) solution to tag proliferation/escalation
is a combination of arbitrary structure and semantic information.
The "preferred" solution will build on an HTML parser and will result in an
HTML-like parser capable of handling arbitrary structure - no DTD or an
optional, minimal one required. It will use CSS or extentions to CSS to add
semantic information to the "new" (and old) HTML tags. In short, this solution
will permit incremental improvement from the then current state of HTML to
something considerably more flexible and long-lived. It will not be SGML nor
will it contain any of SGML's "complexities" but rather will be streamlined for
delivery - a one-way operation.
Assuming that this is HTML's natural evolution, than I would argue that the
initial design of XML should follow this general model. It will be
well-understood by tool developers and explaining it to authors will be
considerably less onerous than describing RS/RE rules or other SGML esoterica.
XML will be accepted as an extension to a well-established, widely-used, and
popular standard. An XML that relies too heavily on SGML mechanisms or is viewed
as overly complex vis a vis HTML will be ignored.
I am strongly in favor of designing initial XML such that it adds minimally to
the complexity of HTML. Arbitrary structure and semantic information are
sufficient. Marked sections, processing instructions, text entities, complex
RS/RE rules, and the like are not required and will delay or prevent accpetance.
We should avoid them. ISO 8879 conformance is not required although I see no
reason to gratuitously preclude it.
I have taken some care to indicate that this would be an initial design for XML.
XML should be extensible and we should expect that it will evolve - perhaps
rapidly. The Web community will expect (demand) no less. As the HTML, no XML
community develops new requirements, solutions can be rapidly uncovered and
presented using SGML as a warehouse. This group, or a follow-on would be viewed
as responding to needs rather than dictating a complex, difficult to implement
If we adopt this approach, one might ask what is SGML's role other than as an
intellectual property repository? Beyond the idea warehouse, it will continue to
be used in many applications because the full expressive power of SGML is
frequently required. Further, SGML engines will be used to convert SGML document
fragments (or complete documents) into XML documents (objects) for delivery to
clients. These transformations and and one-way deliveries would avoid many of
the round-trip SGML-XML-SGML problems that have been discussed here. In short,
SGML is used where required and where the complexity can be managed - on the
server side. XML is used for less "rigorous" applications or where complexity
cannot be tolerated - on the client side.
I've made my plea. I'm sure it will be heard - and I hope some agree with me. If
not, I fear that we will succeed in having interesting discussions but fail in
practical acceptance of XML. Please let's make XML as simple as possible - but
Thanks for your time.