Cart
[Home] [By Thread] [By Date] [Recent Entries]
An interesting and useful page. From: Kohsuke KAWAGUCHI <kohsukekawaguchi@y...> > My motivation is to convince readers to use XML Schema as "DTD+NS+DT", > as I wrote in the introduction. But when XML Schemas was initially being developed, there was a clear view (rightly or wrongly) from the people calling for a schema language that the structures available in DTDs were not good enough. If it were, then Simon's DTD-in-XML language would have been more acclaimed. I agree with Kawaguchi-san's points on notations (the current notation system is half-baked, and just gives them a bad name) and chameleon schemas (does not seem to fit in with the way people work). Several of the comments (e.g. substitution groups, perhaps complex types) seem to be based on the argument that there should never be two ways to get the same result. But there is no reason to suppose that argument to be in general true, unless you are a minimalist (who have consistently failed to produce useful tools, because humans find multiple doors effective.) While I am no fan of type derivation (restriction or extension) of content models, I don't think Kawaguchi's reason is convincing. I think it is enough to say that restriction or extension of content models provides unproven and minimal benefit compared to its complexity: I think most people who look at it will find it does not really give them enough to be useful. (Though perhaps people working on dinasaur RDBMS where changing the schema except by suffixing is an enormous undertaking may find it useful: however, I don't see why XML people should be burdoned with a feature that is required only to help particular implementations.) So I certainly support Kawa-guchi's thrust to the extent that if we all avoid using extension and restriction of content models, it will cause less pain in the future when, I am sure, extension and restriction of content models will be dumped or radically improved. The reason I think Kawaguchi's particular argument "The latter looks like a restriction of the former" is weak, is because it will only "look" that way if someone has not gotten the key concept of type restriction in their head: this is found in section 2.2.1.1 in the Structures document, and says something like "If every instance of type A is also valid against type B, then type A is a subtype of type B". You always need conceptual knowledge to be able to read any markup language. Cheers Rick Jelliffe
|
