Paul Prescod paul at prescod.net
Tue Jun 22 07:07:48 BST 1999

Mark Birbeck wrote:
> I think ultimately it is because it is XML. You now have a document that
> can be parsed and processed with the same tools that you use for all
> your other documents. This makes a number of things a lot easier. 

For programmers. But I asked about usability, not programmability. XML
instance syntax is certainly easier for programmers.

> For example, when we have got a working approach to transclusion
> with XLinks, I could include your schema inside my schema. 

DTDs and W3C XML schemas already do this without any special external
standard. A general transclusion mechanism is not good for schemas anyhow
-- you want to define custom import and export rules.

> For me, though, the main problem with DTDs is not their syntax, but the
> difficulty in validating a document that is based on two or more DTDs.

I was asking about syntax in particular but I am interested in your other

> With the current XML-Data approach, I can define the schema to be used
> on a per-node basis, so including a node also includes the information
> needed to validate it.

Sorry, I don't understand what you are saying here. What XML data facility
allows me to validate XLinks to transcluded "video nodes"? Link validation
is a completely separate issue, IMHO.

> This means that you
> only actually extract the amount of schema you need for the document
> being exported, and it makes schema very easy to maintain (you just have
> to maintain the database). 

You've abstracted away the hard parts of the problem and described how
easy it is to solve the easy ones.

XML's primary goal is interoperability. Company A does not use the same
database schema as company B. The primary purpose of the XML interchange
is to help them to bridge that gap. The bridging can only be done through
haggling, debating and hands-on schema development.

If company A and company B used identically-schemed databases then they
could have used CSV's, S-Exprs or something similiarly simple a decade
ago. Heck, they could have output ten million SQL statements representing
the contents of the database. There's no hard problem there.

> So, to illustrate the point, I have 'objects'
> of type article which can contain objects of type paragraph. When I
> export an article I place on the article node a pointer to the article
> schema. All the latter does is pull out schema information for the
> article and all its children. However, if asked to export just a
> paragraph of text from an article, I attach to that node a pointer to
> the paragraph schema. Why pass any more? The validater doesn't need it.

Piecewise schemas are an orthogonal issue to database generation of
schemas. In most cases it will be simplest to send the whole article
schema and have it be cached on the other side.

But anyhow, from a validation point of view, a schema sent with the data
is not any more useful than the schema you could devise by analyzing the
data! For a schema to be useful for allowing interchange, it must be sent
*in advance*.

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

[Woody Allen on Hollywood in "Annie Hall"]
Annie: "It's so clean down here."
Woody: "That's because they don't throw their garbage away. They make 
        it into television shows."

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)

More information about the Xml-dev mailing list