Parents and children (was RFD: comp.text.xml)

Paul Prescod papresco at technologist.com
Wed May 6 05:48:42 BST 1998


<PHILOSOPHICAL>
len bullard wrote:
> 
> Umm... press in the web is a taken for granted thing now.  As for
> SGML, check the references in the early part of the decade including
> a whole issue of Byte.  

And even another misleading Economist article! And articles in PC
Magazine, etc.

> > This doesn't mean that SGML is evil incarnate - it just means that
> > it involved a learning curve that many people found less than exciting.
> 
> So does XML.  I think once it is out there awhile, you will get to
> endure that as well.  You see, SGML did not start out with that
> reputation.  

To me, this is such a crucial point that it deserves re-emphasis (and
re-re-emphasis). XML inherits 95% of everything that made SGML difficult
to apply and use. Not 95% of what made it hard to memorize the SGML
standard, but that was never relevant, because only one person ever
memorized the standard (at which point, presumably, SGML got boring and he
moved on to other things). But 95% of the stuff that makes SGML hard to
*use* is in XML. The flexibility, the dangerous parameter entities, the
responsibility for defining your own tags, your own stylesheets and your
own systems. The responsibility to define standards and stick to them. The
perceived and real need to bend them. It's all there. 

Compared to HTML, XML is rocket science, just as SGML was before it.

The Byte/Salon/comp....html backlash is a re-occurrence of a very old,
very boring phenomenon. Generic markup makes people's lives harder (in the
short term) in several ways. People have enough on their plates without
digital elites trying to shove down their throats complicated,
multi-layered junk that makes their lives with the promise that it will
have long term benefits.

The best (only?) way to get past that is with instant feedback, immediate
gratification software. Using XML for designing data protocols provides
pretty immediate gratification, which is why it has taken off in that
capacity. On the other hand (and perhaps this is heretical...sorry), the
data protocols world got along okay without XML in the first place. I have
personally documented some interesting applications of XML to software
interoperability problems, but they are essentially incremental changes: a
more expressive IDL, HTTP with richer objects, and so forth. XML makes
these things easier, but not fundamentally more powerful. In my opinion,
XML's real power remains in the ability to make persistent data truly
persistent -- across technological sea changes.

XML browsers will one day provide more or less instant gratification for
Jane Schmoe. She will still have to endure an extra level of abstraction,
understanding and responsibility, but at least she can have her web page
up and running in an evening. At that point, SGML/XML will have really
rounded a corner. Right now, it merely seems to have done so, because it
is the media's interest to promote it as such. And of course it will be
similarly in their benefit to report and perhaps exaggerate the backlash.

Luckily, people are willing (for now) to believe us that we will one day
provide them with more interesting, interactive web pages. This is in
large part because it is in the media's interest to promote that vision
with us. I hope we do not keep the webmasters waiting so long that they
start to disbelieve. Considering that the browser vendors cannot even
implement CSS right, I sometimes have moments of shaky belief myself.
Without the browsers, XML is a programmer's toy and we must begin our
long, slow climb to usability again. Still, with Netscape's source
available, we should not be subject to their whims anymore, so I am not
too worried.

In the meantime, if you teach XML, as I do, I would suggest that the
closest thing to instant gratification we have today is Jade+Docbook for
XML. Creating a series of web pages and a nice printed document from the
same source file is pretty damn cool and much more exciting than looking
at the output of a parser.

<ASIDE>
It will neither help nor hurt pedagogically to admit that these tools
comes from the days before XML, and has been updated for the "Web
generation." You can let your interest in history be your guide on that
issue. Personally, when I teach Java, I like to remind my students of its
(partial, indirect) roots in Lisp (among other languages). I say: give the
devil his due. He may not turn out to be as evil as you thought he was.
</ASIDE>

> In my view, they are the same thing and that is a good thing.  If 
> we have to accept that our *standards* are the product of 
> The Director's approval, and that only the elect can know 
> the shape of things to come such that a Don Park doesn't even 
> have half a chance to compete, then it is time to go back to 
> playing guitar for happy hour crowds.  It is something I 
> understand and can see the good of doing.

It wasn't so long ago that we were having a similarly pessimistic
conversation about web standards (at that time, HTML and CSS) and you
admitted that despite all of the setbacks, it was a good time for
hypertext. That is more true today than ever. XML may still be due for a
backlash, but lights are going on in people's heads all over the place. As
long as the pattern is two steps forward, one step back, we are still
making progress.
</PHILOSOPHICAL>

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

"Perpetually obsolescing and thus losing all data and programs every 10
years (the current pattern) is no way to run an information economy or
a civilization." - Stewart Brand, founder of the Whole Earth Catalog
http://www.wired.com/news/news/culture/story/10124.html

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list