RE: unique/key/keyref identity-constraints

Clive,

The namespaces are visible through mutual import - the schema containing
CLLocation subtypes can import the schema containing CLComponent subtypes,
and vice versa.  All the namespaces and top-level names are globally
visible.

You cannot currently restrict the type of the target of IDREF.  Not only
that, I'm pretty sure you cannot declare a type whose value must be the name
of a type (or element), unfortunately.  So your linkType appinfo element
would have to be defined as of type QName, and its value (here) would be
clLocationNS:CLLocation - you just need to have an appropriate xmlns
attribute.  Your processor might resolve the namespace for you - I'm not
sure - but your application would certainly need to have access to schema
information to do this added level of validation.

Matthew

> -----Original Message-----
> From: JARMAN, CLIVE [mailto:CJARMAN@exchange1.PRIA.com]
> Sent: Friday, February 02, 2001 3:31 AM
> To: Fuchs, Matthew; 'www-xml-schema-comments@w3.org'
> Subject: RE: unique/key/keyref identity-constraints 
> 
> 
> Matthew,
> I dont quite think that this will work for the problem
> we are solving. I omitted to say in the original problem
> statement that we are also referring to the ID elements
> elsewhere in the schema. So a CLLocation derived component
> can refer to a CLComponent derived component by its name.
> If we were to perform the file separation as you say, then the 
> namespace for CLComponents will be hidden from the CLLocation
> derived component, I think.
> 
> Here is an example:
> 
> <xs:complexType name="CLTransferAgent" abstract="true">
> 	<xs:complexContent>
> 		<xs:extension base="CLComponent">
> 			<xs:sequence>
> 				<xs:element name="Location" 
> type="xs:IDREF"
> minOccurs="1">
> 					<xs:annotation>
> 						<xs:appinfo>
> 	
> <linkType>CLLocation</linkType>
> 						</xs:appinfo>
> 					</xs:annotation>
> 				</xs:element>
> 			</xs:sequence>
> 		</xs:extension>
> 	</xs:complexContent>
> </xs:complexType>
> 
> Here, we have extended XML Schema (with the <linkType> 
> element) to let our
> application know
> that the type of the object referred to by name in the 
> "Location" element
> derives from CLLocation.
> However, the xs:IDREF would not resolve to the CLLocation 
> namespace, but
> would instead resolve to 
> the CLComponent namespace, I believe.
> 
> What I would like to say is something like this:
> 
> <xs:complexType name="CLTransferAgent" abstract="true">
> 	<xs:complexContent>
> 		<xs:extension base="CLComponent">
> 			<xs:sequence>
> 				<xs:element name="Location" 
> type="xs:IDREF"
> targetNamespace="CLLocation" minOccurs="1"/>
> 			</xs:sequence>
> 		</xs:extension>
> 	</xs:complexContent>
> </xs:complexType>
> 
> and qualify the namespace to use to resolve the IDREF.
> 
> Have I missed something in your reply?
> 
> Clive
> 
> -----Original Message-----
> From: Fuchs, Matthew [mailto:matthew.fuchs@commerceone.com]
> Sent: Monday, January 29, 2001 3:52 PM
> To: 'JARMAN, CLIVE'; 'www-xml-schema-comments@w3.org'
> Subject: 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 Friday, 2 February 2001 18:49:30 UTC