Courting Joe Homepage
Apologies for the length.
> Taken at another level, more crassly sociological, XML has a greater chance
> of widespread adoption if it doesn't "look weird" to the world's several
> million HTML hacks.
> Someone, please, explain why this fear is unfounded. Because I would
> really like to have a syntactically-obvious EMPTY element in XML. Or
> (serious question) is invading HTML's turf a non-goal of XML?
I'll try. Invading HTML's turf should be a goal, but cleverly
disguising XML as HTML isn't necessarily the best way to do it. I am
not too worried about frightening the HTML hack with weird looking
delimiters. In fact, for the moment, I'm even willing to consider
ideas that might make XML "look weird" to today's crop of WWW
browsers. Here are some of my reasons:
1) SGML already looks weird to the world's HTML hacks. (or, If HTML
looks good, I wanna look bad!)
I doubt that the majority of the world's several million HTML hacks
have ever seen an 8879 conformant document in their lives. I'm not
sure that any flavor of SGML we come up with can have more than a
passing resemblance to the bag-'o-tags they know as HTML. They're
already going to have to learn a lot about XML and HTML (i.e. what
elements are required within others, you can't overlap elements,
etc.) anyhow. A different looking tag delimiter isn't necessarily
going to hurt that process, and might even help.
2) HTML already looks weird to the world's HTML hacks.
Many web page authors are using tools such as Netscape Gold,
Microsoft's Internet Assistant, SoftQuad's HotMetal, etc.
They really don't know, or want to know what HTML looks like.
Our audience will more likely be the tool-smiths and browser
makers. I think they'll accept a different looking <br> tag
if there's a clean, simple, precise specification of XML.
3) HTML hacks are a fickle sort.
I have the feeling that these proverbial HTML hacks do not
have any strong loyalty to HTML, or the RFC. They'll happily
jump on the next "cool thing" to come along if it offers them
the chance to enhance their website with "3-D sense-around in
stereo". XML ought to provide (part of) the infrastructure
to support these cool toys. (Hmmm ... maybe we should try to
make XML look like Java :-))
4) HTML is dead, long live HTxML.
HTML is, IMO, increasingly being viewed as a presentation format,
to be assembled on the fly. Larger web-site Internet and
Intranet publishers are realizing that they have issues
with document management, information reusability, and information
searchability when they try to author to today's popular browser.
They need SGML, but the entry cost has been too high because of its
complexity. The demand for low-cost, robust, powerful SGML is there.
XML can address this demand. Make it so it is super easy for
our CS grad to assemble tools to process it, and the tools will
proliferate. Many of them will take the form of XML->HTML CGI
scripts. Put powerful tools in the hands of the WebMeister,
and he'll know what to do with them.
I think our initial target market is the Internet/Intranet publisher.
Our champion in cracking that market is the WebMeister who finds in
XML a tool that helps him solve his employer's problems. I don't
believe he'll be overly concerned with how closely XML resembles HTML,
as long as its rules are easily understandable with a minimum of special
With a sufficiently simple design, it won't take too long before
browsers and search robots which can take advantage of XML's
expressive power are implemented. Web page authors will move to XML
because of the new things it lets them do, not because all they need
to do is replace "<HTML>" with "<HTXML>", and make sure they've
explicitly opened and closed all the elements.
For as long as possible, I'd like to keep the primary focus on those
first four design principles identified in DD-1996-0001. When forced
to choose between simplicity and elegance, or making it look like
HTML, my inclination is toward doing the Right Thing(TM).
William D. Lindsey
+1 (303) 672-8954