XML complexity, namespaces (was WG)

[Marcus Carr]

Chris Lilley wrote on SGML:

> Uh, this is actually a fairly big driver for people working in XML too.

So... if I was taking potshots at it, it might be indicative that I'm missing something, right?

The reason that people have been marking data up as SGML for many years now is because there was no
XML. We were anticipating its arrival, but until it came we knew we had to mark up the data in some
way that would ensure that it was useful for many years to come. We didn't know what future
technology would hold and to some extent, still don't. What shape will the web be in ten years?
Will loosleafing paper documents survive, or be forced out by smarter data handling and delivery?
Two valid questions ten years apart.

There is what I believe to be a misconception amonst some portions of the XML community that XML
and SGML are locked in some sort of competition, but I don't see any of the same feeling from the
SGML community. The conclusion that I draw from this is that there is some sort of insecurity,
perhaps due to the fact that XML feels that it must replace SGML in order to ensure its survival.
The SGML community sees XML as a great boon - a truly sweet way of using the data and realising the
long-term effort that they have put into their datasets.

Not only does XML address the long-term storage issues that motivated people to move to SGML
(despite the absence of a proliferation of tools), it also addresses putting the data to work. The
SGML community isn't bitter about this - it is exactly what we want. Many organisations now have
huge SGML datasets that can be XML compliant in a couple of days. XML vindicates those of us who
have been pushing SGML for years.

> I'm not saying that its impossible to get value from it, or that it is
> without power. But it is significantly underpowered in some ways, and
> pays too big a price in parsing complexity for minor keystroke savings,
> and the original design constraints don't necessarily apply to todays
> applications, which is why I see XML as more powerful than SGML, not
> less, in spite of being (now) a subset of SGML.

One reason that SGML came about was that organisations were starting to amass large datasets that
were being locked into proprietary applications. Two issues that (I suspect) drove features like
tag omitability were the conversion of these large legacy sets and the perception that in the
absence of SGML tools, politically, markup would have to as simple as possible. The standard may
well have been skewed toward the user and away from the application developer, but I don't think
it's fair to retrospectively bag this decision just because the methods that we now use to collect
and tag data have evolved. Any general comparison of which is "more powerful" is invalid - XML is
capable of very much more than SGML is, but someone with a huge repositiry of SGML documents that
can be valid XML in a week is surely in a "more powerful" position than someone just starting to
collect XML data.

> Well if you are an SGML user who is not
>
> a) involved in furthering the XML effort, or
> b) involved in slowing down the XML effort
>
> then I didn't categorise you at all, since I was speaking of only two
> particular portions of the "old SGML community". There are, of course
> other portions; and there are, of course, other communities.

Is there a "new SGML community" as well? Now I'm not even sure what suburb I live in. I've put a
down payment on a flash new house in XML, but I want to hold on to my familial house in SGML. It
would be foolish to sell it now, when it continues to provide solid, long-term gains. Besides, I
have friends there.


--
Regards,

Marcus Carr                      email:  mrc at allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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)