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 
standard.

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 
no simpler.

Thanks for your time.

Bill

Received on Tuesday, 1 October 1996 22:22:46 UTC