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

Your note deserves a detailed response  Unfortunately, I am on the road at 
a conference this week, so won't get to it next week.  In short, I believe 
you are right that the Rec is tricky in this area, and probably should be 
clarified.  It's possible that I have misrepresented some nuances, but I 
think the overall conclusion is about right. 

I'll try to do this in brief with time available, and if that doesn't 
cover it we'll have to leave it for next week.  Note the quote from the 
same section:

"Note that components to be imported need not be in the form of a ·schema 
document·; the processor is free to access or construct components using 
means of its own choosing."

and

"It is not an error for the application schema reference strategy to fail. 
It is an error for it to resolve but the rest of clause 2 above to fail to 
be satisfied. Failure to find a referent may well cause less than complete 
·assessment· outcomes, of course."

So, we've basically said:  "Your processor can use any strategy at all 
that it wants for identifying components for namespace A". 

You ask:

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

and you quote:

" The ·schema components· (that is {type definitions}, {attribute 
declarations}, {element declarations}, {attribute group definitions}, 
{model group definitions}, {notation declarations}) 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"

Right, but what is "I"?  It is a schema that exists only if you chose to 
have a reference strategy that succeeds, and as is clear from the above 
that's at your option.  So, while I would have presented it somewhat 
differently, I don't think the import requires you to do much or anything 
>except< that if you admit to having a strategy that succeeds in 
referencing a document, then you must indeed include the corresponding 
schema.  You can always claim to have a strategy of some sort that didn't 
succeed, hence no obligation I think.  Again, I think this is a somewhat 
unfortunate way to present things, and other experts may disagree with my 
interpretation.  (Henry?  I think you've disagreed with my interpretations 
in this area at some point along the way.) 

Hope this helps.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Alessandro Triglia" <sandro@mclink.it>
10/26/2003 09:58 PM

 
        To:     "[Public XML Schema-DEV]" <xmlschema-dev@w3.org>, 
<noah_mendelsohn@us.ibm.com>
        cc: 
        Subject:        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 Monday, 27 October 2003 19:06:53 UTC