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

Re: Included <schema>

From: George Cristian Bina <george@oxygenxml.com>
Date: Wed, 13 Feb 2013 10:28:47 +0200
Message-ID: <511B4EBF.5010605@oxygenxml.com>
To: Michael Kay <mike@saxonica.com>
CC: xmlschema-dev@w3.org
Thanks Mike,

Sometimes I know that I know something but I do not know how I got that 
knowledge and trying to get the relevant part of the spec if usually 
difficult.
Probably a FAQ for XML Schema will help a lot, similar to what Dave 
Pawson did for XSLT.

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

On 2/12/13 10:36 PM, Michael Kay wrote:
>
> On 12/02/2013 09:48, George Cristian Bina 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.
> Yes, this is the consensus interpretation of the spec.
>>
>>
>> 1.2 It resolves to a <schema> element information item in a
>> well-formed information set, which in turn corresponds to a valid schema.
> The phrase "corresponds to a valid schema" has always been highly
> problematic. Henry Thomson points out that a dangling reference to other
> components does not itself make a schema invalid. However, it is
> difficult to argue that there is a "valid schema" corresponding to an
> included schema document containing a type whose base type is defined in
> the including schema document. Such a schema might contain, for example,
> a simple type whose {variety} is unknown, and the SCM is explicit that
> in a valid schema, the variety of a simple type must be atomic, union,
> or list.
>
> I think the only way out of this dilemma is to adopt highly creative
> interpretations of the terms "corresponds to" and "valid schema",
> neither of which is rigorously defined in the spec.
>
> XSD 1.1 is a lot better in this regard, though still not nearly as
> rigorous as I would like. It solves the problem by defining inclusion at
> the level of schema documents, not schema components.
>
> I have learnt over the years that implementing XSD is a bit like
> implementing HTML - often you have to do what other implementations do,
> or what Henry and Michael say the spec was intended to mean, not what
> the spec actually says. I hope this will prove less true of XSD 1.1; and
> reading XSD 1.1 is often a good way of determining the consensus
> interpretation of XSD 1.0.
>
> Michael Kay
> Saxonica
>
>
Received on Wednesday, 13 February 2013 08:29:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 February 2013 08:29:12 GMT