I think this is a limitation of the Microsoft processor. To get around it we would have to refactor the union type, sacrificing some reuse and abstraction. I'm not sure that this is the kind of thing W3C should be doing.

It is possible that the MS processor is actually right, the base type is a union and the derived type restricts by pattern in a union (does this invalidate 3.3.2.4 of W3C XML Schema?).

There's an easy fix though, I validated it successfully by replacing

  <xs:simpleType name="QName-or-EQName">
    <xs:union memberTypes="xs:QName">
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:pattern value="Q\{(.*)\}[\i-[:]][\c-[:]]*"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>

with:

  <xs:simpleType name="QName-or-EQName">
    <xs:restriction base="xs:token">
      <xs:pattern value="Q\{(.*)\}[\i-[:]][\c-[:]]*"/>
    </xs:restriction>
  </xs:simpleType>

Which, without looking at it too carefully, seems to be a fair change.

At the same time I am wondering why we call something "QName-or-EQName" when the pattern only allows the EQName format (with leading "Q").

The change Abel proposes leads to a different PSVI (or typed XDM instance), Just saying.

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.

(In reply to C. M. Sperberg-McQueen from comment #4)
> it should raise the same error on json-node-output-method-type.
Yes it does, I can confirm that.

(In reply to C. M. Sperberg-McQueen from comment #4)
> 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.
It appears to behave consistently, as far as I could see [1].

> 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.
Yes, I missed that, thanks.

> 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 *-->
>    <snip />
I can confirm that the proposed solution in comment 4 worked (but should be applied to json-node-output-method-type as well.

> Alternatively, we could declare types
>   - Prefixed-Name (a QName with a colon)
>   - Qualified-EQName (an EQName with a non-empty namespace name)
This appears to work as well.

[1] https://github.com/Microsoft/referencesource/blob/d925d870f3cb3f6acdb14e71522ece7054e2233b/System.Xml/System/Xml/Schema/SchemaSetCompiler.cs (line 612, Res.Sch_UnionFromUnion is the error raised).

If we are going to refractor, I would prefer something like the second alternative in comment 4 with no nested union types.

At the meeting on 2016-06-07, the WG agreed to allow the schema expert to fix the schema, and for implementers to test the fix.

ACTION A-645-07: MSM to prepare a schema with a workaround for the
issue reported in bug 29658 and post it.

ACTION A-645-08: TM to test the schema prepared by MSM to address the
issue raised in bug 29658. (Depends on action A-645-07.)

ACTION A-645-09: JS to test the schema prepared by MSM to address the
issue raised in bug 29658. (Depends on action A-645-07.)

ACTION A-645-10: OND to test the schema prepared by MSM to address the
issue raised in bug 29658. (Depends on action A-645-07.)