Smart but useless, part 3

Smart but useless, part 1
Smart but useless, part 2

Now that I have the derived types that I want, how do I use these?
The answer is given in the dcterms schema itself.

In order to specify one of these ... an xsi:type attribute must be used in the instance document.

For example:

<dc:creator xsi:type="dc:Agent" scheme="overheid:Gemeente">Antwerpen</dc:creator>

This is OK, both from a schema point of view and from the semantics of this dublin core element.
But look at the following examples. They are OK schemawise, but do they make sense?

<dc:creator xsi:type="dc:URI">http://www.antwerp.be/</dc:creator>
<dc:creator xsi:type="dc:Date">2008-06-06</dc:creator>
<dc:creator xsi:type="dc:Spatial" scheme="overheid:Postcode">3000</dc:creator>

The next example is showing the opposite; it is NOT correct schemawise since xsd:date is not a validly derived datatype from 'SimpleLiteral', but semantically it makes sense:

<dc:modified xsi:type="xsd:date">2006-12-12</dc:modified>

The solution would be that we can constrain the allowed types on xsi:type, BUT we can't. See also the note included in the dcterms schema.

Also, note that one shortcoming of this approach is that any type can be
applied to any of the elements or refinements. There is no convenient way
to restrict types to specific elements using this approach.

This whole approach can only work if the content creator knows and the type system and which type to use on which element.

It's our opinion that this is too much asked for. It is the schema designer who needs to be in charge of datatyping, not the content creator.

Other remarks related to xsi:type:

• Paul Downey :: xsi:type is Evil
• Norman Walsh :: xsi:type Train Wreck
• Rick Jelliffe :: Snow Season in Schemaland

Possible Solutions

One way of dealing with the problem of constraining the possible datatypes is using another attribute to enumerate the allowed datatype.

<dc:creator type="Agent" scheme="overheid:Gemeente">Antwerpen</dc:creator>

where the schema constraints the value of attribute type on element creator to "Agent", followed by the trick learned from Michael Kay

... to add the xsi:type attribute using a SAX filter; you then pipe your original source into the schema validator via the filter. Quite a few of the limitations of XML Schema 1.0 can be overcome by validating not the original document, but a simple transformation of it.

However I still do not find this satisfying for a solution that is not centralized and needs to work in standard XML editing environments.

Conclusion

What should have been a small schema design assignment turned out to be constant struggle with the hideously complexities and expected but missing functionalities of XML schema 1.0.
The fact that the dcterms schema took as one of its premises one of the most contested features, didn't help either.

So I decided to rewrite the dcterms schema from scratch, leaving the semantics intact but changing the schema approach completely.