Lists Home |
Date Index |
- From: Mark Birbeck <Mark.Birbeck@iedigital.net>
- To: email@example.com
- Date: Wed, 4 Aug 1999 15:51:16 +0100
Rick Jelliffe wrote:
> Mark Birbeck wrote:
> >... My argument is based on a recognition that
> >what elements of a schema I need depends on what is the
> purpose of the
> >XML document to which the schema refers. For example, if I have two
> >servers that sit all night passing data to each other, the purpose of
> >the schema is simply to validate the integrity of the data passed.
> Now you are changing the goalposts! Verbosity is a
> disproportion of the
> schema w.r.t. the data or its use; if you are passing the same kind of
> data between servers all night, the verbosity question does not arise.
No - I was only illustrating the fact that how much schema you need
depends on what is happening to the data. For example, if the XML
document can be modified you need to include all possible children, but
if the document cannot be modified, why bother sending definitions of
nodes that are not in the document being passed - an 'instance' of many
possible documents that could be developed from the larger schema?
> > If one server sends:
> > <time>1201</time>
> > <station>123</station>
> > <status>56</status>
> >why bother sending more schema info than the name of the
> root document
> >and the two children that it has?
> But so could a DTD. I could have
> <!DOCTYPE statusReport SYSTEM
> atus ">
> and have the DTD generated at the server. The DTD could be generated
> from data marked up in instance syntax, for ease of implementation, if
> you like! The server that generates the data can also generate the
> correct URI.
I agree. I made the point that dynamically generating a DTD is about as
easy as dynamically generating any other type of definition. My argument
related to the point that schemas are verbose (in response to the
100k/1k point), NOT that they are inherently better than DTDs because
they can be dynamically generated.
However, I did go further and say that I thought schemas were better
because they could take advantage of other XML tools, and because they
had a simple route open for solving the problem of a document being
validated by multiple DTDs or schema.
> > The solution used in IE5 - where
> > the namespace definition can be used to point to a schema for that
> > - allows documents to effectively contain other documents.
> >People kept thinking that there needed
> >to be a document at the end of a namespace URI, and that it would be
> >used to validate. Even though they were wrong, they thought that
> >it has a nice intuitive feel to it.
> First you praise IE5 for doing it, then you say it is wrong. I am
> missing something.
You are. I said they WERE wrong, as in, at the time of the great
namespaces debate, people intuitively thought that declaring a namespace
would validate their document because there would be a DTD at the
end-point of the URI. The fact that this feature has now been introduced
in IE5 (although with a schema at the end-point) doesn't mean that
people hadn't misunderstood the namespace specification, just that they
felt it should do more. In fact the namespace definition says that the
URI doesn't have to point to anything, which long-suffering list members
will remember caused a LOT of confusion and controversy.
> The best way to future-proof schemas is to represent them in an ISO
> language, certainly not in a language developed by a vendor's
> So DTDs more certain: in fact, their unique syntax prevents mutations.
> There is no need to say "DTDs or Schemas"--DTDs *and* Schemas can
I think future-proofing is only possible if we can manipulate our data
definitions as easily as we manipulate the data they define. Trying to
force everyone to use the same schemas is unlikely to work - although
don't everyone come back on me and say I am advocating not having
standards! I'm just being realistic.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)