Re: XML Schema: DOs and DON'Ts

[Rick Jelliffe <ricko@allette.com.au>]

An interesting and useful page.

From: Kohsuke KAWAGUCHI <kohsukekawaguchi@yahoo.com>

> 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