Re: Included <schema>

Thanks Henry,

Regarding the lazy component construction my understanding of that was 
that during the schema creation when a module is read it may contain 
references that cannot be be resolved at that time but they should still 
be resolved when all the modules are read. This seems to be also what 
Saxon and Xerces do as they report an error on a schema like:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="content">
     <xs:complexType>
       <xs:sequence minOccurs="0">
         <xs:element ref="a"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>

   <xs:element name="test" type="xs:string"/>
</xs:schema>

even if I validate an instance document that refers only to the "test" 
element:

<test xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="m.xsd">
</test>


Engine name: Xerces
Severity: error
Description: src-resolve: Cannot resolve the name 'a' to a(n) 'element 
declaration' component.
URL: http://www.w3.org/TR/xmlschema11-1/#src-resolve

Engine name: Saxon-EE 9.4.0.6
Severity: fatal
Description: The element {a} is referenced, but has not been declared

Xerces refers to the #src-resolve section of the spec as the reason for 
this error:
http://www.w3.org/TR/xmlschema11-1/#src-resolve

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 2/12/13 1:04 PM, Henry S. Thompson wrote:
> George Cristian Bina writes:
>
>> I always thought that an included schema document may refer to
>> components that are defined in the including <schema> even if they are
>> not directly reachable if we start from the included schema.
>
> True, IMO.
>
>> Now, the spec says in http://www.w3.org/TR/xmlschema-1/#src-include:
>> ***
>> Schema Representation Constraint: Inclusion Constraints and Semantics
>> In addition to the conditions imposed on <include> element information
>> items by the schema for schemas, all of the following must be true:
>> 1 If the ·actual value· of the schemaLocation [attribute] successfully
>> resolves one of the following must be true:
>> 1.1 [...]
>> 1.2 It resolves to a <schema> element information item in a
>> well-formed information set, which in turn corresponds to a valid
>> schema.
>> ***
>>
>> Does this "which in turn corresponds to a valid schema" mean that the
>> above schema starting from test.xsd should be considered invalid
>> because m.xsd is not valid itself?
>
> Ah, but m.xsd _is_ valid.  The open reference (to 'a') does not render
> the schema invalid.  Just as in DTDs, including an element (ref.) in a
> content model is only an error if you need it to validate a particular
> part of an instance:
>
>    Note: The pervasive impact of redefinition reinforces the need for
>    implementations to adopt some form of lazy or 'just-in-time'
>    approach to component construction, which is also called for in
>    order to avoid inappropriate dependencies on the order in which
>    definitions and references appear in (collections of) schema
>    documents.
>
>    When schema components are constructed from XML representations
>    involving reference by name to other components, this assumption may
>    be violated if one or more references cannot be resolved. This
>    specification addresses the matter of missing components in a
>    uniform manner, described in Missing Sub-components (§5.3): no
>    mention of handling missing components will be found in the
>    individual component descriptions below.
>
>    [M]ost kinds of schema components have properties which are
>    described ... as having other components, or sets of other
>    components, as values, but that when components are constructed on
>    the basis of their correspondence with element information items in
>    schema documents, such properties usually correspond to QNames, and
>    the ·resolution· of such QNames may fail, resulting in one or more
>    values of or containing ·absent· where a component is mandated.
>    [I.e. it's a validation-time error, not a schema error.]
>
> ht
>

Received on Wednesday, 13 February 2013 08:11:23 UTC