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

Noah wrote:

----------------
[...] 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... [...]
----------------


You seem to be saying that the above ("adding to the schema all the components ...") occurs *if* the schemaLocation attribute is present in the <import> (implying that it does not occur in the absence of a schemaLocation attribute). However, this is not what I understand from the recommendation.

The relevant passages in Part 1 are:


--------------------
Schema Representation Constraint: Import Constraints and Semantics

[...]

The ·schema components· [...] of a schema corresponding to a <schema> element information item with one or more <import> element information items must include not only definitions or declarations corresponding to the appropriate members of its [children], but also, for each of those <import> element information items for which clause 2 above is satisfied, a set of ·schema components· identical to all the ·schema components· of I.
---------------------


where "clause 2" is a few lines above:


--------------------
2 If the application schema reference strategy using the ·actual value·s of the schemaLocation and namespace [attributes], provides a referent, as defined by Schema Document Location Strategy (§4.3.2) [...]
--------------------


and:


---------------------
Schema Representation Constraint: Schema Document Location Strategy 

Given a namespace name (or none) and (optionally) a URI reference from xsi:schemaLocation or xsi:noNamespaceSchemaLocation, schema-aware processors may implement any combination of the following strategies, in any order: 

1 Do nothing [...]

2 Based on the location URI, identify an existing schema document [...]

3 Based on the namespace name, identify an existing schema document [...]

4 Attempt to resolve the location URI [...]

5 Attempt to resolve the namespace name [...]
----------------------


Since  "Schema Representation Constraint: Schema Document Location Strategy"  allows locating a schema document by using the namespace name (whether or not a schemaLocation attribute is also provided), I don't see how the presence of schemaLocation can make a difference, as to whether or not the set of components from the imported namespaces become part of the Schema.

My understanding is that schemaLocation:

- is optional; 
- if it is present, the processor may use it as a hint or ignore it;
- its presence or absence has no other effect.


Moreover, I disagree with your statements:

----------------------
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.  
----------------------

in that the <import> is more than a mere hint to tools that a component with a certain target namespace may be referenced later in the document.  The addition to the Schema of all the components built from the imported namespace may affect for example:

- the composition of element substitution groups;
- the set of global element declarations available for validating the document element of instances;
- etc.

Also, given the above, a "recursive import" is indeed a meaningful phrase, because if I have document A with an <import> for the namespace of document B, which has itself an <import> for the namespace of document C, then the Schema will necessarily consist of all components built from C, plus all components built from B, plus all components built from A.

The rationale for this is in the wording used in the Recommendation (as quoted above):  "a set of ·schema components· identical to all the ·schema components· of I".

("I" being a "valid schema", not a "schema document".)  I understand "valid schema" as a Schema that conforms to XML Schema, which requires the incorporation of components from imported schemas.  In other words, the  "valid schema I"  to which  "the <schema> item SII"  corresponds (see the Rec) cannot just be the set of components built from the <schema> item SII, but must contain all the components built from the <schema>s that are reached via resolution of the <import>s present in <schema> item SII.

Even though the recommendation doesn't say it explicitly, my interpretation is that an <import> item imports a full Schema (based on the namespace and/or location of a <schema> item SII), which may include other namespaces if the imported Schema has itself one or more <import> items.  Otherwise, I cannot make any sense out of the phrase  "a valid schema I".

Alessandro

Received on Sunday, 26 October 2003 21:59:57 UTC