[
Lists Home |
Date Index |
Thread Index
]
On Wed, 2003-12-17 at 07:38, Bullard, Claude L (Len) wrote:
> Two only slightly related questions:
>
> 1. Why did XML keep the requirement for deterministic models?
At a quick approximation, my recollection is: for
compatibility with SGML. If a nondeterministic model
were legal in XML, then the subset relation between
legal XML documents and legal SGML documents would
have been lost. James Clark and Tim Bray also argued
that implementations could make good use of the fact
that legal models are all deterministic, and wanted
to retain it for that reason, as well.
A related question: why did XML Schema retain the
requirement? I believe there are several answers
here: non-determinism makes it harder to write
streaming processors (less of an issue for systems
that provide the downstream app only with a single
validity bit than for systems which provide type
information and element-by-element validity
information), some people made the better-for-implementors
argument again, and I suspect some WG members felt
that it would be safer to start by imposing the
restriction than by removing it: if you start
with the constraint, it's possible to relax it in
a later version without breaking existing schemas,
but if you start without a constraint, adding it
later will break things, and is thus often
impossible.
Me, I still hope for the day we can eliminate it,
but I'm not holding my breath. If you have use
cases and a desire to see the rule relaxed, a note
to the comments list at www-xml-schema-comments@w3.org
would be very useful to those of us interested in
pursuing this question.
> 2. What are good reasons for having multiple schemas for the same
> instance?
For the same instance, or for the same namespace?
Here are some off the top of my head; some relate to instances,
and some to namespaces:
- the namespace in question is not a single language but
a family of related languages (e.g. (X)HTML)
- you have two schemas that do very different
things, and the documents you really want to accept
are those in the intersection of the two languages
- you wish to ensure both that your document matches the
generic schema of a particular trading group and also
matches your internal process rules (your trading group
says billing address is optional, your own rules say
it's required; the generic schema allows costs to be
any decimal number, you say that no invoice item may
be for less than a dollar, ...)
- you wish to check that a document is legal both for
trading group X and for trading group Y (good trick if
you can do it, but if you can do it, you'll have
multiple schemas for that document)
- you wish to decive your trading partners into thinking
that you are sending them valid data, so you produce
an alternative schema for the namespace, in which you
make all of your documents legal
I guess most of these are just variations or instantiations
of the second item in the list.
Just my two cents, and speaking here only for myself.
-C. M. Sperberg-McQueen
World Wide Web Consortium
|
