Re: Fwd: Re: A Plea for Schemas

Date view Thread view Subject view Author view

From: Stephen D. Williams (
Date: Wed Feb 23 2000 - 11:38:36 PST

XML isn't perfect, and isn't applicable at all to certain situations like
multimedia encoding, but it provides a crystalizing core that allows us to
clean and replace all of the prior business communication cruft.

Ka-Ping Yee wrote:

> .....
> XML is versatile, yes. That is great. But it *solves*
> nothing. The problem of getting people to agree on
> standards for communication data formats will always be
> there, and XML does not make that problem go away, no
> matter what illusions some people seem to have. It's
> no different than sending around some LISP s-expressions.
> We have had this and other data structures for decades.

As in many areas, it's not the fundamental details that are important but the
accepted body of idioms that gives something like XML it's power.

This is definitely the case for Java and C++ is a good counter example.

Both Java and XML have been a chance for people to assemble and synthesize
better ways of doing things. There are many things that I could point to in
Java tools, applications, and idioms that could have been done before but
seemingly were just not worth the effort until you had this whole new
generation of technology with which to make a clean start.

The XML groups, participants, and to some extent developers all expect certain
characteristics to be present in many circumstances that in a previous data
model mindset wouldn't have been seriously considered.

Some examples:
Schema migration (you are expected to ignore elements you don't understand,
but these should not be discarded),
standards based naming,
self-describing data formats,
arbitrarily extensible standards,
I18N support,
standardized macro capabilities,
broadranged validation ability,

Sure, all of these things existed before, but not in a general format,
standard, and body of tools with a culture designed to make it all work.

The culture is more important than the specifics of the format.

> Yes, it's nice to be able to send trees around. We have
> lots of ways of sending trees and lists and various kinds
> of structures around. Let's add another one to our
> repertoire. But let's not let this get out of hand, please.
> Choosing to use XML means (a) you get to sling a fancy
> buzzword around and (b) you get to make work coding yet
> another XML parser and generator immediately, so you can
> do some satisfying programming to keep your hands busy
> while you figure out what you're going to do with it.
> When people say "XML technology" it makes me want to laugh.
> How would you react if someone said they were going to
> "build an electronic communications solution using
> powerful ASCII technology"? XML is not a technology,
> people. It's a data format, for crying out loud. Yes,
> something like XSL could be a technology. But not XML.

Tools that implement XML idioms at various levels do constitute technology.
Code to handle overlayed trees with a mix of append and replace updates, for
instance, can save a lot of development effort.

> When people say "we're going to use XML" they're actually
> communicating hardly any bits. Just as if someone said
> "we're going to use ASCII", you look at them like they
> haven't said anything, and wait for the details.

While fundamentally true now, I expect this to change. There is a big
difference now between a simpleminded XML approach and a more rich handling of
extensible, flexible data objects that have complex lifetimes. I am Not
talking about DTD's which, in my point of view, should only be used for formal
forms, documents, and as a specification of the syntax range of a protocol
rather than being used to do feeble and expensive validation at run-time.

Part of the problem is that we have yet to develop lingo that is more specific
to the rich range of data management problems that can be tied to XML's

> -- ?!ng


-- - Revolutionary E-Business Communication Stephen D. Williams  Senior Consultant/Architect
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax  Jan2000

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 11:46:33 PST