[Bug 29658] [SER31] Problem with schema

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29658

--- Comment #4 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
Thank you, Tim.  I am a bit torn here:  the creation of unions whose member
types include facet-restricted unions is something that XSD 1.0 got wrong.  (It
declared all member types substitutable for their unions, which in this case
would allow EQName to be substituted for QName-or-EQName and for method-type,
thus subverting the pattern facets on each of those unions.)  It looks as if
the Microsoft validator is imposing a constraint not defined in XSD 1.0, and
slightly different from the repair used in XSD 1.1.  If it is behaving
consistently, it should raise the same error on json-node-output-method-type.

Since none of the types involved in the serialization schema involve
substituting member types for unions, it's not clear that the validator is
justified in raising the error.  That is, nothing in the schema actually
exploits the bug in XSD 1.0.  It would be helpful if the validator told us just
what rules in XSD it thought were being violated here.  (Perhaps the fact that
it doesn't signals that it is compensating for a bug in the spec?)  But it is
clear that raising the error does prevent the problems found in XSD 1.0. 

So I am agnostic about changing the schema and will defer to others whose
judgement is not clouded by history.

MK is right to say in comment 1 that we can work around the problem by
refactoring the union.  I'm not clear that the loss in reusability or
abstraction is over-high, given the simplicity of this schema.  

W.r.t. comment 2:  I do not think that either of the union types method-type or
QName-or-EQName violates clause 3.3.2.4 of Schema Component Constraint:
Derivation Valid (Restriction, Simple) in XSD 1.0.  The rule reads:

  Only pattern and enumeration facet components are allowed among the {facets}.

And indeed only those two facets are used in either of the two union types (or
any of their members).  XSD 1.1 has no clause so numbered in this constraint.

The union type QName-or-EQName is not misnamed; the first member is QName; it
appears as the value of the 'members' attribute, rather than as a child.

IF the WGs decide to change the schema, I think a simple workaround would be to
move the pattern facet from the member to the union, expanding it to handle the
enumerated value of xs:token as well:

   <!--* not tested *-->
   <xs:simpleType name="method-type">
    <xs:restriction>
      <xs:simpleType>
        <xs:union>
          <xs:simpleType>
            <xs:restriction base="xs:token">
              <xs:enumeration value="html"/>
              <xs:enumeration value="text"/>
              <xs:enumeration value="xml"/>
              <xs:enumeration value="xhtml"/>
              <xs:enumeration value="json"/>
              <xs:enumeration value="adaptive"/>
            </xs:restriction>
          </xs:simpleType>
          <xs:simpleType>
            <xs:restriction base="output:QName-or-EQName"/>
          </xs:simpleType>
        </xs:union>
      </xs:simpleType>
        <!--* value must have non-null namespace URI *-->
        <xs:pattern
value="(x?html|text|xml|json|adaptive)|(.*:.*)|(.*\{.+\}.*)"/>
    </xs:restriction>
  </xs:simpleType>

Alternatively, we could declare types

  - Prefixed-Name (a QName with a colon)
  - Qualified-EQName (an EQName with a non-empty namespace name)

and use those instead of a restriction of QName-or-EQName when we construct
method-type and json-node-output-method-type.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 24 May 2016 17:19:27 UTC