This time I remembered to trim the included messages.
Hopefully this will be a bit les tedious.
Yesterday I wrote:
>
> Jane -
> I've been down this track a couple of times so have one
> comment to add:
>
> There is one way only in W3C XML Schema of defining
> an element from which other elements can be derived
> which can have either simpleContent or complexContent -
> that is to declare an element with anyType that acts
> as the head of a substitution group:
> either
>
> <element name="DCField" type="anyType"/>
> or
> <element name="DCField"/>
>
> where in the latter construction the type is implied.
> Then any other element of any type can be declared
> to be in its substitution group, e.g.
>
> <element name="DCDate" type="date" substitutionGroup="DCField"/>
>
> where "date" is a built-in simpleType from XML Schema, or
>
> <element name="DCCoverage" type="your:favoriteCoverageEncodingType"
> substitutionGroup="DCField"/>
>
> where favoriteCoverageEncodingType is a complexType in "your"
> namespace.
> But don't try deriving simpleContent types by restriction from
> an anyType parent - there is "magic" involved in deriving the
> simpleTypes side of the type hierarchy which is not to be
> exposed in real schema documents!
>
> Also, do not make the mistake of defining an empty complexType
> and then trying to add simpleContent - it doesn't work.
>
> And you also cannot derive specific simpleContent types
> from string, unless using lexical patterns is acceptable.
>
> And even the correct XML Schema syntax for deriving types
> by restriction from anySimpleType is muddy - different
> schema validators seem to have different interpretations
> of the spec (there is a bug in XML Spy, for example -
> I can forward my correspondence with Altova if anyone is interested!)
>
Pete Johnston replied:
>
> Thanks for this information, Simon. I hadn't got that far, but I was
> coming to the conclusion that most of my efforts to work
> round this were
> really dead-ends.
>
> Does it follow from this that we should (can?) create XML
> Schemas _only_
> to describe specific "application profiles"? - following Andy's view
>
>
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0203&L=dc-architecture&F=&S=&
P=8462
>
> of constructs like "Simple DC" (and, I imagine, "Qualified DC") as
> application profiles, which I think may be helpful here.
>
> They may not be application-specific, but they describe usages of DC
> elements in a particular way (which in these cases may be useful to many
> applications), where content models/data types can be specified (even if
> in some cases they may be looser/broader than others)
> Maybe this is just stating the obvious, but it might help stop me
> tilting at the windmill of a "generic" XML Schema to describe the
> elements in the namespace. ;-)
Simon replies now:
Yeah - I think this might be right.
Note that it is not /XML/ that is deficient here, it is W3C XML Schema.
The main advantage of XML Schema is its data typing system.
However, that comes at a cost.
One of the limitations is that "simple" types are in a completely different
hierarchy to "complex" types (i.e. ones with sub-elements).
As I noted, the hierarchies only join at one point - the top.
Then there are some tricks that can be pulled with "mixed" types - i.e.
element content which includes text interspersed with elements.
This all means that it is very tricky to build a base system which it is
possible to refine to both simple and complex types.
And this is at the centre of the simple vs qualified DC issue.
|