W3C home > Mailing lists > Public > xmlschema-dev@w3.org > February 2013

Re: Included <schema>

From: George Cristian Bina <george@oxygenxml.com>
Date: Tue, 12 Feb 2013 13:07:12 +0200
Message-ID: <511A2260.80808@oxygenxml.com>
To: Mukul Gandhi <gandhi.mukul@gmail.com>
CC: xmlschema-dev@w3.org
Hi Mukul,

Thanks Mukul for pointing out that this part is removed in XML Schema 
1.1. Yes, it is clear that m.xsd is invalid if we validate it 
standalone. The problem I have is if m.xsd should be considered invalid 
according to XML Schema 1.0 also when we start from test.xsd.

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

On 2/12/13 12:58 PM, Mukul Gandhi wrote:
> Hi George,
>      The XSD 1.1 spec at the same place mentions only this,
> <quote>
> 1.2 It resolves to a <schema> element information item in a well-formed
> information set.
> </quote>
>
> The 1.1 spec doesn't say "which in turn corresponds to a valid schema."
> I think, with an XSD 1.1 processor test.xsd would correspond to a valid
> schema. With both XSD 1.1 and 1.0, m.xsd in isolation would be invalid
> (since the element reference, <xs:element ref="a"/> within it cannot be
> resolved).
>
> On Tue, Feb 12, 2013 at 3:18 PM, George Cristian Bina
> <george@oxygenxml.com <mailto:george@oxygenxml.com>> wrote:
>
>     Hello,
>
>     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.
>
>     More clearly the following sample should be valid:
>
>     test.xsd
>     <xs:schema xmlns:xs="http://www.w3.org/__2001/XMLSchema
>     <http://www.w3.org/2001/XMLSchema>">
>        <xs:include schemaLocation="m.xsd"/>
>        <xs:element name="root">
>          <xs:complexType>
>            <xs:sequence maxOccurs="unbounded">
>              <xs:element ref="content"/>
>            </xs:sequence>
>          </xs:complexType>
>        </xs:element>
>        <xs:element name="a" type="xs:string"/>
>     </xs:schema>
>
>     m.xsd
>     <xs:schema xmlns:xs="http://www.w3.org/__2001/XMLSchema
>     <http://www.w3.org/2001/XMLSchema>" elementFormDefault="qualified"__>
>        <xs:element name="content">
>          <xs:complexType>
>            <xs:sequence minOccurs="0">
>              <xs:element ref="a"/>
>            </xs:sequence>
>          </xs:complexType>
>        </xs:element>
>     </xs:schema>
>
>     Now, the spec says in
>     http://www.w3.org/TR/__xmlschema-1/#src-include
>     <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?
>
>     Neither Saxon EE nor Xerces report problems when validating test.xsd
>     so my guess is that there is some other place in the spec that allow
>     this case and maybe the "corresponds to a valid schema" here does
>     not mean that the module itself is a valid schema but that all the
>     modules that define components in the same namespace should form a
>     valid schema.
>     Anyway, I will appreciate some insight into this.
>
>     Best Regards,
>     George
>     --
>     George Cristian Bina
>     <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
>     http://www.oxygenxml.com <http://www.oxygenxml.com/>
>
>
>
>
> --
> Regards,
> Mukul Gandhi
Received on Tuesday, 12 February 2013 11:07:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 February 2013 11:07:33 GMT