XSDL best practices question/suggestions

Roger,

I've been inexcusable lax in following your best practices efforts, but the
question from Clive Jarman caught my attention and reminded me of a
discussion I had with Martin Gudgin in London that I think is significant,
particularly in preventing <include> and <redefine> from making a total mess
that it will take us a long time to fix.

In particular, as I not below, the XSDL composition mechanism, which is just
a rehash of what we did for SOX2, was intended (at least as I designed it)
to be used in a very particular pattern - a root file containing just a list
of includes, and several other files containing no includes, but possible
imports.  The goal of this is to localize, as much as possible, file system
dependencies - only the root file needs to be changed if file names change,
or items are redistributed among modules, or new items are added.  Otherwise
all the files of the schema need to be examined and potentially changed.
This may not seem like such a problem when using small schemas with one or
two files, but the joy grows rapidly thin with extremely large schemas, such
as xCBL3.0 - which has almost 400.  It is only the file "XCBL30.sox" that
has any includes (called join in Sox).  Note that anyone who downloads CBL,
or any other large, componentized schema, would be well advised to use a
better file resolution mechanism than local file names - or they'll be
writing a lot of useless sed scripts.

Note that with this architecture I can easily eliminate the include element
and it's a trivial step to either send partial schemas around or to store
them in a database.  I can also create smaller or larger collections, as
need be, by just editing the root file.

I'm pleased to see that Rick Jeliffe's proposal for XHTML seems to make a
distinction between include files and definition files - although with two
levels of include.  I would want to see a explicit statement that the
disctinction should be _strict_ - includes at the top, definitions at the
leaves, and that the includes form a tree, not a dag.  The tree restriction
is to support redefine - with a tree it is impossible for any component to
be included twice, so there can be only one redefine and no includes.  With
a dag, there can be multiple redefines and includes - and that's one of
those corner cases where you're likely to find inconsistent behavior among
processors.

Please let me know if this makes any sense to you.

Thanks,

Matthew

> -----Original Message-----
> From: Fuchs, Matthew 
> Sent: Monday, January 29, 2001 12: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 Monday, 29 January 2001 19:20:47 UTC