... something should be added here, currently only technical requirements and problems with that are discussed below! ...
Schema design and namespaces
For the last two weeks I am struggling to find a good design for a common UBIF and multiple, specialized BDI.SDD_, ABCD, and TaxonConcept schemata. Some of the requirements are (see also BDI.SDD_ Schema Design Principles):
The UBIF base schema should validate stand-alone, with different payloads. That is a single UBIF Datasets collection should be able to hold multiple dataset objects with different payloads (e.g. one has names, the other descriptions, several more specimen unit data).
This can be achieved with a xs:any (ns=#other) element at the end of Dataset. Originally I run into validation problems when using two namespaces (the payload was no longer validated, but this could be partly resolved and partly confirmed as a long-standing bug in xml-spy, compare UBIF.DesignWith2NamespacesDoesNotValidate!
The schemata should be constructed with standard xml namespace conventions, implying the use of elementFormDefault"qualified" attributeFormDefault"unqualified" in schema design. With elementFormDefault="unqualified" the behaviour of embedded elements in instance documents (i.e. not the element bearing a complex type, but those contained within it) depends on whether a default namespace (no prefix) or a namespace with a prefix is used.
The payload schemata should reuse a library of common types to simplify the design of builder and consumer applications, especially when object-oriented programming languages are used.
In principal this is possible using a common library (UBIFLib.xsd). However, this is complicated by bugs in applications and namespace issues. The chameleon design pattern, using included libraries without a targetNamespace (and which then acquire the namespace of the including schema is a good solution, and both ABCD and BDI.SDD have so far used such libaries. While a single schema always works, as shown in TwoNsAttempt1.zip this runs into multiple compatibility issues (or bugs in xmlspy) when attempting to combine two schema, that are based on the same library. Although XML spy is not the measure of all things, it is worrysome if already such a widely used tools in unable to cope with a design.
Searching for a work-around, I tried copying the library, so that UBIF and BDI.SDD_ include the same information from files with different names. The hypothesis was that the bug in xmlspy is due to mistaking filename and namespace. However, this did not improve the situation, see TwoNsAttempt1b.zip.
In TwoNsAttempt2.zip the problem was solved by using text cut-and-paste instead of the schema include command. As documented in the read me file in the zip, even this solution behaves quirky, depending on which schemata have been opened previously. With a freshly started xmlspy, however, it could be used. It is not elegant, since updates in the base library have to be manually introduced into the participating schemata.
Finally, some types cannot be moved into a base library, but are by necessity tied to UBIF rather than UBIF_Lib.xsd. This occurs because of the use of identity constraints (= key/keyref mechanism) to link the definition of proxy objects with references to them. XML Schema unfortunately stipulates that identity constraints can only be defined on elements, not on types. Furthermore, the key must be defined in the common root of all key and keyref-occurrences. Within the UBIF structure this is the Dataset element. Therefore types like MediaResourceRefType, PublicationRefType, but also the derived citation or revision data types are by necessity in the UBIF namespace.
A result of this is that at rather unexpected locations a UBIF namespace (defined as ub in the following examples) must be used. For example, although both Icon and MediaResource are based on the UBIF MediaResourceRefType, one needs a prefix, the other not. Similarly, a list of multiple citations has the namespace at Citation, a single citation not! Examples from SDD_tech.xml in TwoNsAttempt2.zip for mixed namespace usage:
UBIF is a stand-alone schema in its own namespace that does support unrelated payload schemata with different namespaces.
UBIF_Lib is a library of reusable base type definitions without a target namespace, it acquires the namespace of the importing schema (e.g. UBIF.xsd)
It is not recommended to both import UBIF.xsd and include UBIF_Lib.xsd, although in theory this should work. (Please help if you can make more sense, see the situations detailed in TwoNsAttempt1.zip and TwoNsAttempt2.zip.)
If a payload schema like BDI.SDD_ wants to reuse UBIF concepts like references to publications, agents, locations etc. it must either accept a mix of its own namespace and UBIF namespace elements, or it should use the UBIF namespace itself. This is unexpected to me and seems unfortunate (and contradicts Tom Gaven's Best Practice conclusion 4), but is the best I can find.
As a result, to allow both other and own namespace, the xs:any extension at the end of the UBIF Dataset element had to be changed from "##other" to "##any" namespace.
This is what is proposed in UBIF10b9_SDD091b25.zip. However, note that this is not a full solution. It means a UBIF namespace may either be validated through UBIF.xsd with other unrelated schemata, or under a related schema. That is for BDI.SDD_ document have xsi:schemaLocation="http://www.tdwg.org/2004/UBIF BDI.SDD.xsd"!!! This makes them combinable with other namespace payloads, but if ABCD would use the same one-schema approach, we would have to construct a master schema combining BDI.SDD, ABCD and all others that base themself on the UBIF namespace. This is possible, does not feel right or elegant - but I am tired out after two weeks reading schema documentation, best practices, testing bugs in spy - and I have to stop working on this... Please someone come in to help!
If we accept that the library needs to be physically included rather than using xs:include (as done in TwoNsAttempt2.zip), the rather confusing use UBIF namespace inside BDI.SDD_ could be improved. The ref elements and collections would not be used through types, but rather through model groups (like the EnablingGroup) that contain the elements. The Citation would always be ub:Citation, etc. The problem with this is that this fixed the element name to the one defined in the base libary (whereas using types, the element name can be freely choosen at the point of usage). However, the number of element names used is either 1 or rather low (e. g. Icon used instead of MediaResource for a MediaResourceRef). -- Any opinion?