W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2003

RE: Changing "substitutionGroup" to "choice" and maintaining the validation equality of the schema

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 17 Oct 2003 17:05:05 -0400
To: "Lemmin, Harald" <Harald.Lemmin@softwareag.com>
Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Message-ID: <OF9F0B8E29.74A0F51F-ON85256DC2.006CB608@lotus.com>

I'm not sure I'm following all of this in detail , but I'm fairly 
convinced there's some confusion in this thread regarding imports, schema 
documents and schemas.  Here are some rules that may help:

* First, some terminology:
- Schema document:  an XML instance with root <xsd:schema>, that 
represents declarations and definitions, all of which share a namespace 
(or all of which are not namespace qualified)
- Schema:  the combination of components you're going to use for a 
validation, independent of namespace, imports, which schema document they 
came from, etc.  For example, the schema includes all the element 
declarations, type defintions etc. used in a validation.   A schema treats 
all namespaces symmetrically:  each declaration or definition just carries 
the namespace (if any) and local name being declared.

* The substitution group mechanism isn't namespace sensitive in any 
interesting sense, as it works at the schema level.  If anywhere in a 
schema a particle in a content model is a reference to a substitution 
group head, then that will validate all members of the group, regardless 
of namespace, and regardless of the type or schema document in which the 
reference appears.

* Import works at the schema document level, and there is no such thing as 
a recursive import.   Import is essentially a cross check and hint to 
tools.  It basically makes explicit the external namespaces from which 
your document will draw components.  It also provides a hint in the case 
you choose to provide a schemaLocation, but that's not mandatory in any 
case.  If you study the design carefully you will see that, other than the 
schemaLocation hint, it would work identically without import at all.  A 
ref="ns1:xxx"  could be resolved just as well without the import.  The 
import just gives early warning to the processor that such constructions 
may occur >in this schema document<.  This can be confusing so let me 
state it differently:  the only time import matters is when there is an 
explicit reference to a namespace from a schema document, and these are 
not inherited transitively.   Or stated yet another way:  an import gives 
permission for a schema document to make references to another namespace, 
but in no other way does it change the semantics of the schema document or 
the schema being constructed (if a schemaLocation is provided, and if the 
processor chooses to honor that hint, then the import has the additional 
effect of adding to the schema all the components corresponding to the 
imported document...because they are added to the schema, they are equally 
visible from all other schema documents, including those that define 
substitution group heads with which some of the imported components may 
affiliate themselves.  Imports for the same namespace are needed on other 
documents if and only if those documents make explicit reference to the 
imported namespace.)

Back to the basic question, I think but am not 100% sure that the choice 
is indeed equivalent to the substition group >>for any particular 
schema<<, and I mean schema not schema document.  A schema is essentially 
a closed, fixed set of components.  If you look at the schema document 
level, the story changes.  If I have:


   schema targetNamespace="ns1"
 element A (abstract=true)
 element B (substitutionGroup="A")
 element C (substitutionGroup="A")
 element D () - sequence - element (ref="A")

then I can only be sure of what to put in the choice if I know of all the 
other elements, perhaps from other namespaces or perhaps from other 
documents declaring more components for ns1 (which would be somewhat 
unusual without an include, but legal if your processor got it e.g. from a 
command line argument).   Keep in mind:  schema documents are just units 
of serialization:  you can't bound the members of a substitution group 
until you see the whole schema, but then I believe you can.   If you know 
the complete schema, then I believe that a choice is completely equivalent 
to a reference to the substitution group. 

Hope this helps.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Friday, 17 October 2003 17:06:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:03 UTC