Last week I described my problems with using the proposed DCQ schemas
as a basis for community-specific and 3rd party qualifiers
[http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=0&F=&S=&P=5596].
In brief, we need to create a version of the qualifieddc container which is
extensible, permitting elements from other namespaces to be included
[cf sec 6, http://dublincore.org/documents/2002/09/09/dc-xml-guidelines/].
It seems to be impossible to use XML Schema to define an extensible
container (permitting ##other content) when the existing content comes
from multiple namespaces (dc, dcterms, olac) and not just the single
targetNamespace [http://www.xfront.com/ExtensibleContentModels.pdf].
In further experimentation I have created an olac:qualifieddc
container which incorporates dc, dcterms and olac elements, and a
hypothetical third-party extension which targets the *same* namespace,
but with its own local schema file. The schema files and validated
examples are at: http://www.language-archives.org/test/2002-09-30/
I don't really like this solution, since I'd like our participating
archives to be able to start using new qualifiers without having to
define a whole new container element. They should be able to supply
the schema fragment for a set of terms or a string format.
Therefore, any suggestions for a better way to set up extensible
containers would be most welcome.
--
Implementation Notes.
The schemas and instance documents referenced above illustrate two
approaches to setting up an extensible container. The first tries to
stick closely to the DCMI approach of using full XML elements for
refinements. The second approach uses xsi:type overrides for
everything. In the XML files, I've called these the ELEMENT APPROACH
and the XSI:TYPE APPROACH respectively. Since there's a large amount
of shared schema between the two approaches, I've put them both
side-by-side in the same files, but used comments to distinguish them.
The advantages of the element approach are twofold. First, it permits
formal validation of the association between elements and encoding
schemes. If a refinement stipulates an encoding scheme, as with
OLAC's subject-language property, then this is enforced. There's no
room for third parties to make up their own association, unless they
license it formally by providing a new schema. Second, the element
approach permits the metadata representation to be implementation-
neutral, as it doesn't contain XML Schema validation directives. This
means we can switch validation technologies without necessarily
revising the metadata format.
-Steven
--
Steven Bird Email: <[log in to unmask]> Web: http://www.cs.mu.oz.au/~sb/
A/Prof, Dept of Computer Science, University of Melbourne, Vic 3010, AUSTRALIA
Senior Research Assoc, Linguistic Data Consortium, University of Pennsylvania
|