Lists Home |
Date Index |
- From: Paul Prescod <firstname.lastname@example.org>
- To: "'email@example.com'" <firstname.lastname@example.org>
- Date: Fri, 29 Jan 1999 14:06:08 -0600
"Simon St.Laurent" wrote:
> I've noticed a very unfortunate trend among certain members of the XML
> community. Whenever someone proposes using XML in any way that goes beyond
> interchange and documents, they become very concerned that the system
> proposed won't work and that the sky will fall in on XML.
Perhaps that's because we've seen many of these systems not work.
> XML is many things to many people. It is simple enough and generic enough
> that if you try hard enough, you can stretch it to fit just about any
> problem in computing.
That's exactly what I'm afraid of! You can also stretch a screwdriver into
hammering nails, but that doesn't mean it is a good idea.
> It may not always be the optimal approach, but it
> fits many problems very well.
I agree. XML is the perfect solution to many interchange and archiving
> XML has, in
> many ways, left behind its roots as a document format and become something
> else, a generic set of tools for manipulating information.
The problem is that when you add a level of "XML" to your system, you add
complexity. Here are examples from my customers:
* they could use STEP EXPRESS or ODL to model objects in a system. Instead
they want to use DTDs. Now I have to figure out the mapping from elements
to objects. They've added complexity and inefficiency to the system. They
either have to serialize the objects to verify their conformance or build
a "DOM" interface over the existing object model. Why bother?
* they want to use XSL as their "object search" technology instead of
OQL. Now they have to map their logical object searches into
tree-searches, cross-pointer searches into hyperlink-traversing searches,
and so forth. Once again, they've got an extra layer that they don't need.
Now here's the sad thing: I choose to help them with these projects
because I realize that the tools that they really need are not properly
deployed, so they must use XML-centric technologies as a proxy. EXPRESS is
not implemented in object databases (AFAIK!!!). There are no free OQL
implementations (AFAIK!!!). Using XML as a proxy for robust object
technologies is a hack, but it works.
(serializing Java objects as XML elements makes perfect sense *if* you are
going to do something with those objects that you couldn't otherwise do
(i.e. load them into a C++ program). i.e. XML is GREAT at interchange. It
is also very good for working with documents, where the XML representation
is created by a human and "is" the object as far as the computer is
(one problem with these languages is that their web-presence is not good)
> Tools that work for XML will work on data across an enormous number of
> domains, and if those tools follow similarly generic standards, they may
> even work across implementations from an enormous number of vendors using
> very different technology. I don't feel that we've achieved nirvana, but
> for the first time we may actually have an opportunity to genuinely move
> toward interoperable computing without having to all be using the same
> languages and platforms, and that's a big step.
I don't see how that paragraph applies uniquely to XML. I could say the
same things about Unicode, Java, SQL or TCP/IP. They also *could* apply to
STEP/Express and OQL if it weren't for the fact that the XML hype is
obscuring their existence.
> Why does XML have an opportunity, when SGML had the same tools and more?
> Because it's simple enough for neophytes to walk up to and explore, and
> because processing it isn't very hard. Two good things that lower the cost
> of development significantly.
What XML has is hype. The reason it has hype is because it comes from the
W3C and it is easy enough to make a parser for it that programmers feel
like they could do it "if they had to" even if a small minority choose to.
Neophytes have been walking up to and exploring SGML since the first free
parser became available a decade ago.
> > * Isn't OQL pretty close to an XML query language?
> > * Aren't STEP and ODL ...
> You can wander back into the woods if you like, but don't expect everyone
> to follow you. Heading back to implementation-specific standards is
> necessary for some applications, but it isn't going to work across the
In what sense is OQL more "implementation specific" than XSL or XQL? In
what sense is ODL more "implementation specific" than DTDs or XSchema. You
need an implementation of any of them, sure, but they can be implemented
in any language just as XML or SQL can be.
> > * Wouldn't it be nice to have more formal mechanisms for characterizing
> >angle-bracket syntax?
> Your last point about formal mechanisms is worth considering, though I'm
> not sure it's 'the opposite direction' at all.
It's the "opposite direction" (in some sense) if it allows us to abandon
angle brackets in favor of more human-friendly notations when they are
> But I'd rather see the W3C invent something new that works
> on the Web than leave us with older tools that don't work well on the Web.
We don't know whether they work on the Web because nobody has ever tried
to adapt them for the Web. We're reinventing things first and "asking
> What's XML for? Anything you like. Build it, and see if people come.
You can say that about anything. That doesn't mean that every tool is
equally good for every job. It is possible to abuse XML just as you can
abuse a screwdriver.
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
Don't you know that the smart bombs are so clever, they only kill
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)