RE: unique/key/keyref identity-constraints

Sir,

It seems to me that you may be able to get what you want by using 3
different schemata.  In XSDL a namespace corresponds to a single schema, so
if you put all the elements/types derived from CLLocation in one schema,
those derived from CLcomponent in a second schema, and those derived from
CLIOSensor in a third, then you get a namespace for each.  Each schema can
<import> the other two, so there is no problem with cross references.

In terms of the physical structure of Schemas to support this, note that the
composition mechanism of XSDL is a "bastardization" of the Java composition
mechanism - a schema equates roughly to a package.  We have an import
facility, but it indiscriminately imports all of the target namespace, and
we still have an include mechanism pointing to distinct objects, rather than
leaving that to the runtime (as Java does).  As with Java, each individual
file claiming to belong to a particular schema should have the same
targetNamespace as that Schema (although this, too, is not strongly
enforced) - the goal (at least from my perspective) being to eventually junk
"include".  Therefore I recommend you structure your schema(s) as a tree,
with a root file containing only includes and no definitions, and the other
files containing imports and definitions, but no includes.  This way, your
only file system dependency is in the root file - redundant with a slightly
more intelligent processor.  You can extend the schema to your heart's
content by adding files that include new definitions, so long as you add an
include to the root document - the files with definitions don't need to know
about the locations of other files (or which definition is where) because
that is handled by the root document through its includes.

In other words, there is a root document to start:

<schema targetNamespace = "CLLocationSchema">
  <include target = "CLLocation.mod"/>
</schema>

Then there is a document containing the definition for CLLocation:

<schema targetNamespace = "CLLocationSchema">
  <complexType name = "CLLocation">...</complexType>
</schema>

When you want to create a subtype, you add a new file for the subtype:

<schema targetNamespace = "CLLocationSchema">
  <import targetNamespace = "CLIOSensor"/> !! - note that imports are scoped
to a single schema element
  <complexType name = "CLSubtype"><complexContent><extension
base="CLLocation">...</complexType>
</schema>

and to make sure this is included by any processor looking for this schema,
you modify the root document:

<schema targetNamespace = "CLLocationSchema">
  <include target = "CLLocation.mod"/>
  <include target = "CLSubtype.mod"/>
</schema>

I hope this helps - I must admit that I stopped programming in C++ before
the addition of namespaces.

Matthew Fuchs

> -----Original Message-----
> From: JARMAN, CLIVE [mailto:CJARMAN@exchange1.PRIA.com]
> Sent: Monday, January 29, 2001 4:38 AM
> To: 'www-xml-schema-comments@w3.org'
> Subject: 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 15:52:43 UTC