unique/key/keyref identity-constraints

I have been asked by Alexander Falk, President of Altova, Inc to submit
comments on 
the unique/key/keyref identity-constraints to you.

We at PRI Automation are using XML to store configuration information for
our product set of 
Semiconductor Automation equipment and using XML Schema to validate the
configurations.

XML Schema was a natural choice for us because its type hierarchy map more
or less 1:1 with the
C++ type hierarchies in our software. However, there is a problem that is
expressed in C++ that does
not easily fit into XML Schema as it currently stands - that of specifying
unique namespaces for all
types in a type hierarchy.

Our C++ objects all have names (a string) which is modelled in XML Schema as
a Name attribute.
However, we have three distinct namespaces in our codebase for the names of
objects, and these
namespaces depend on the hierarchy they come from.

Objects derived from CLLocation have 1 namespace.
Objects derived from CLcomponent have a different namespace.
Objects derived from CLIOSensor have yet another namespace.

So two objects that come from different hierarchies can have the same name,
but no two objects
within the same hierarchy can have the same name.

The problem with the current XML Schema unique constraint is that it is
dependent on the structure
of the XML document, not on the type hierarchy that makes up the Schema.
This means that in order
to express the constraint, all derived types of these (abstract) base
classes have to be speciifed:

		<xs:unique name="UniqueSensors">
			<xs:selector xpath="//CLISensor | //CLOSensor |
//CLClearErrorOSensor | //CLDTOSensor | //CLOSensorShared"/>
			<xs:field xpath="@Name"/>
		</xs:unique>

		<xs:unique name="UniqueLocations">
			<xs:selector xpath="//CLNewIOPort| //CLIFTSPort|
//CLNewAutoIOPort| //CLAutoIOInnerInput| //CLAutoIOInnerInput_CA |
//CLAutoIOInnerOutput | //CLAutoIOInnerOutput_CA | //CLAutoIOOuterInput |
//CLAutoIOOuterOutput | //CLNewMIOPort | //CLNewMIOInputPort |
//CLNewMIOOutputPort | //CLNewOpenerPort | //CLBOCSOpenerPort |
//CLNikonOpenerPort | //CLTurboBOCSOpenerPort | //CLSamsungBOCSOpenerPort |
//CLNewPPort | //CLPPortSiemens | 
//CLPIOActivePort | //CLPIOActiveVehiclePort | //CLWTUPort | //CLPodPort |
//CLBOCSPodPort | //CLSecsPodPort | //CLTurboBOCSPodPort | //CLRotatorPort |
//CLToolPort | //CLVCPort"/>
			<xs:field xpath="@Name"/>
		</xs:unique>

When more types are derived from the base class, then the Schema author has
to remember to manually update this xpath
expression in order for the new type to be included in the namespace.

If there was only one namespace in our model, then xsi:ID would nicely fit
the bill.
<xs:complexType name= "CLLocation" >
	<xs:attribute name="Name" type="xsi:ID"/>
</xs:complexType>
<xs:complexType name= "CLComponent" >
	<xs:attribute name="Name" type="xsi:ID"/>
</xs:complexType>
<xs:complexType name= "CLIOSensor" >
	<xs:attribute name="Name" type="xsi:ID"/>
</xs:complexType>

However, we have three and so this will not work.
May I suggest an extension to xs:ID that accepts an additional namespace
tag?
<xs:complexType name= "CLLocation" >
	<xs:attribute name="Name" type="xsi:ID" IDnamespace="CLLocation"/>
</xs:complexType>
<xs:complexType name= "CLComponent" >
	<xs:attribute name="Name" type="xsi:ID"
IDnamespace="CLComponent"//>
</xs:complexType>
<xs:complexType name= "CLIOSensor" >
	<xs:attribute name="Name" type="xsi:ID"  IDnamespace="CLIOSensor"//>
</xs:complexType>

Now, I dont really like this, and I am not advocating removing the current
way of specifying uniqueness
by the document structure, but some method of tying the uniqueness of
elements to the type hierarchies
in XML Schema would be a very welcome and powerful addition.

Yours sincerely

Clive Jarman, pHD
Principal Software Engineer
PRI Automation Inc.

Received on Monday, 29 January 2001 07:36:55 UTC