Included <schema>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Included <schema>

George Cristian Bina-2
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">
   <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"
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:
***
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

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Mukul Gandhi
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 <[hidden email]> 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">
  <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" 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:
***
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




--
Regards,
Mukul Gandhi
Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Henry S. Thompson
In reply to this post by George Cristian Bina-2
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
--
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

George Cristian Bina-2
In reply to this post by Mukul Gandhi
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
> <[hidden email] <mailto:[hidden email]>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Mukul Gandhi
On Tue, Feb 12, 2013 at 4:37 PM, George Cristian Bina <[hidden email]> wrote:
Yes, it is clear that m.xsd is invalid if we validate it standalone.

I would like it to be believed like this. Henry T has given a formal definition wrt this. I can't seem to reason, that what he has said might be wrong.




--
Regards,
Mukul Gandhi
Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Henry S. Thompson
In reply to this post by Mukul Gandhi
Mukul Gandhi writes:

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

Not so -- see my response.

ht
--
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Michael Kay
In reply to this post by George Cristian Bina-2

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


Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

George Cristian Bina-2
In reply to this post by Henry S. Thompson
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

George Cristian Bina-2
In reply to this post by Michael Kay
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Henry S. Thompson
In reply to this post by George Cristian Bina-2
George Cristian Bina writes:

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

That's not the way I read it.

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

XSV is happy with that pair.

ht
--
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [hidden email]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

Michael Kay
In reply to this post by George Cristian Bina-2

On 13/02/2013 08:10, George Cristian Bina wrote:
> 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.
The specification says that all references required for validation must
be resolvable. It doesn't say which references are required for
validation. I think the designers of the language had in mind that the
rules should be similar to those for DTDs (or for SGML), where absent
references are allowed in content models provided the element in
question is not encountered. But the rules in XSD are much more
complicated; for example you can't tell whether "element declarations
consistent" is satisified without following all the references, so if a
reference is unresolved, you have to assume this constraint is violated.
In addition, users really don't want the situation where they use a
schema successfully to validate hundreds of instances, and are then told
during the next validation episode that the schema is incomplete. So in
practice I made the decision that there are so few cases where a schema
with dangling references is usable that I don't allow it. This is
conformant, because a processor is allowed to use as many references as
it chooses during validation, and to fail if any of them is unresolved.

Michael Kay

Reply | Threaded
Open this post in threaded view
|

Re: Included <schema>

C. M. Sperberg-McQueen-2

On Feb 13, 2013, at 6:09 AM, Michael Kay wrote:

>
> On 13/02/2013 08:10, George Cristian Bina wrote:
>> 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.
> The specification says that all references required for validation must be resolvable. It doesn't say which references are required for validation. I think the designers of the language had in mind that the rules should be similar to those for DTDs (or for SGML), where absent references are allowed in content models provided the element in question is not encountered.

For what it's worth, I think that that is true.

Not clear (particularly at this distance in time) is whether everyone in the
WG had the same understanding of just what it would mean concretely for
the rules to be  "similar to those for DTDs".

In particular, I suspect there may be different views on what was intended
to happen if we have a declaration of element E with optional children A, B, C,
and D, and if we also have declarations for A, B, and C, but no declaration for
element D.  I believe some members of the WG would have said that we
can happily validate elements like <E><A/></E> and so on, and the only
difficulty come if we encounter a D element in the document instance.  I
suspect (but cannot say for certain) that other members of the WG would
 say we cannot validate any instances of E, because we don't have a fully
checkable declaration for E.  

> But the rules in XSD are much more complicated; for example you can't tell whether "element declarations consistent" is satisified without following all the references, so if a reference is unresolved, you have to assume this constraint is violated.

This is an excellent example of the kind of complication that come into
play.  My sense of the original idea was that if a reference is unresolved,
the idea was to assume that all relevant constraints were satisfied, not
violated, since the idea was to make validation produce useful results even
in the presence of transitory network outages.  Others in the WG could
well argue otherwise -- but in that case, the decision to impose constraints
like that, and to expect a pessimistic, rather than an optimistic, behavior in
the face of unresolved references should not have been taken without considering
its impact on the (allegedly) settled design principle that network failures
should not render a document invalid nor validation impossible.  

Unfortunately, it was never possible to generate a consistent consensus in
the WG in favor of facing up to such difficulties squarely, so the day was
carried by those in the WG who simultaneously maintained (a) that we had
satisfied the requirement that missing components not cause problems,
and (b) that missing components must cause an error in appropriate
circumstances, (c) that there is no need to specify more precisely exactly
what those circumstances are, and (d) that XSD's interoperability record is
satisfactory.

The result is the sad state of affairs now seen in the XSD 1.0 and 1.1 specs,
whose rules for schema construction are simultaneously underspecified and
contradictory.  

There was a brief period during the development of XSD 1.1 when it seemed it
might be possible to set the treatment of schema construction on a better
footing by attempting to find a set of clear and coherent rules that would be
consistent with whatever behavior we found to be implemented consistently by
existing processors and whatever assumptions we could find consistently
applied in existing schema documents.  But one vendor's representative
objected to basing further work on examination of behavior by existing
implementations and insisted that we must preserve compatibility with the
existing wording of 1.0 at all costs.  (By which, as events later showed, he
apparently meant not the text of 1.0 but his understanding of what he had
wanted during the development of 1.0, quite independent of what the text
of 1.0 actually says.)  

We did as this vendor representative demanded, but the cost was unfortunately
to leave a large number of contradictions in place in the text and to leave
users interested in interoperability without any serious help.  

Oh, well.  Live by consensus, die by consensus.

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************