XML complexity, namespaces

[Richard L. Goerwitz]

Paul Prescod responded on a number of fronts to my posting, covering
topics such as the utility of SGML, his old CS friends' attitudes to-
ward it, and the existence of good, easily accessible software to pro-
cess SGML.

A response is in order, because he's actually arguing against a posi-
tion I do not hold.

Paul says:

> Software to work with XML doesn't work so great yet either. The most
> sophisticated, solid software I have that work with XML (e.g. Jade,
> Excosoft Documentor) was all SGML software first. Do you have some
> counter examples?

XML has only been around a short while.  It's not a fair comparison.

By way of contrast, SGML has been around a long time.  If there's not
a lot of good software out there for it by now, I don't think I'm being
unreasonable in claiming that it's, at least in part, because SGML is
a mess.

Re your CS friends who belittled SGML:  If it was the concept of des-
criptive markup that they belittled, then they were just silly.  And
I think most of them would admit that now.  But if it was the formal
properties of SGML, specifically DTDs, that they were belittling, then
there's very little question that they had a point.

Now re James Clark:  SGML defenders typically hold up his amazing work
as evidence that SGML is easy to process, and quite elegant.  Within a
rather restricted domain, that's true.  But it's really not fair to use
JC as prima facie evidence of elegance or simplicity.  He's worked long
and hard, and he's done some work that's frankly amazed the rest of us -
and the industry.

In a sense, though, all of this is moot.  Your comments seem aimed at
refuting an argument I never made.  I am not saying that you couldn't
get work done with SGML.  I'm not even saying that, for its time, it 
wasn't a tremendous advance.  I'm just saying what should be obvious to
any impartial observer:  That it could stand a lot of improvement, and
that we now have a chance to make the improving easy on ourselves by
making a clean break, on the XML schema issue, with SGML.

Re XML and SGML, you say:

> The syntactic differences between them have so little to do with the
> complexity of making industrial strength applications that I can only
> conclude that those who think that SGML implementation is "hard" and XML
> implementation is "easy" haven't actually got around to implementing
> anything complex yet.

Paul, just for the record:  I have done a lot of implementation work,
some of it quite complex.  Again, though, you're refuting an argument
that I never made.  Far from characterizing the difference between SGML
and XML as hard vs. easy, I have criticized the W3C repeatedly for let-
ting XML become cluttered and disunified, and for letting the old "CS
student can implement a parser for it in a week" become a cruel joke.

> It doesn't make sense to wait for schemas in order to implement a new
> system

This is a good point you make.

As soon as possible, the W3C should make known its intentions.  The worst
possible outcome here would be for them to push DTDs and all the junk that
goes with them to make them useful (architectures, etc.) - only to replace
the whole mechanism by recommending a new or alternate schema setup later
on.

If we're going to get another schema setup, then let's just live with DTDs
as they are for now.  Skip architectures.  Then let's move on to the new
schema mechanism when it's ready.

Until then, we can live with the namespace debacle.

-- 

Richard Goerwitz
PGP key fingerprint:    C1 3E F4 23 7C 33 51 8D  3B 88 53 57 56 0D 38 A0
For more info (mail, phone, fax no.):  finger richard at goon.stg.brown.edu

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/ and on CD-ROM/ISBN 981-02-3594-1
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)