Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@w... 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
|
