an unfilled need

Paul Prescod paul at
Fri Sep 10 17:23:27 BST 1999

Sean Mc Grath wrote:
> [Paul Prescod]
> >All you've done is shifted the problem from document type design to API
> >design. Now you need the "bank debit golden ration rte interest group"
> >to standardize their Bank objects and Debit methods.
> But this only becomes an issue whenever there is
> a need to interface between disparate systems. 

But if you don't need to interface between disparate systems why did you
bring the "bank debit golden ration rte interest group" into it? They
aren't relevant whether you take the declarative XML or programmatic
Javascript path.

> Case in point: There is no industry standard markup language
> for creating a collapsible table of contents in a Web page.
> There is a very nice one running on the Isogen site
> ( written in JavaScript.

Sure, but it doesn't need XML.

> XML gives me a beautifully simply, open systems, way
> of expressing a hierarchical data structure. Why would
> I throw that away?

XML is no simpler than a language's custom pickle (serialization)
format. If more than one language is involved then XML starts to become
more compelling but at that point we're getting back into the realm of

We are mostly in agreement: client-side arbitrary processing is
certainly a good thing. As a matter of taste I see no reason to embed
that program in the same XML document as the data. You can't embed Java
classfiles that way and even if you could it is better to refer to the
program so that it can be cached seperately.

 Paul Prescod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list