如何允许我的复杂类型中的任何类型的元素排除导入模式中的类型/元素

Question

I am writting a xml schema(lets say A) and it imports another schema(lets say B). I have a complex type (lets say it is named CT) and it lists sequence/choice of elements defined in B. I want to allow any element in the sequence/choice but list some of them explicitly. How do I do that ? For example

<xs:schema xmlns:b="http://B" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:a="http://A" targetNamespace="http://A">
        <xs:import namespace="http://B"/>
                <xs:complexType name="CT">
                    <xs:sequence minOccurs="0" maxOccurs="unbounded"> <!-- using choice is a possible option -->
                        <xs:element ref="b:e1" minOccurs="0"/>
                        <xs:element ref="b:e2" minOccurs="0"/>
                        <xs:element ref="b:e3" minOccurs="0"/>
                        <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                    </xs:sequence>
                </xs:complexType>
    </xs:schema>

The problem with this schema is that it is ambiguous. The validation does not pass because the "##other" namespace allows any namespaces different from A => it is possible to use elements from B but some of them are already declared in the choice/sequence and that is where the ambiguity comes from.

Note: The order of B:e1, B:e2, B:e3 is not defined.

One would ask "why would you like to do that" ?

Because I am using JAXB to generate some classes from this xml schema. I know the elements B:e1, B:e2, B:e3 most probably will be there and I have special workflow for them (so I need java object representation for each of them) and I don't really have to handle the other possible elements (but they should be allowed).

Note: I can not use include instead of import, because the B schema is predefined and targets different namespace.

So does anyone knows how to exclude B from ##other ? Any other solutions are welcome.

Thank you.

Answer 1

This is straightforward in XSD 1.1, because in 1.1 when a wildcard competes with an xsd:element element, the xsd:element element wins. (In 1.0, the pattern you illustrate produces a violation of the 'Unique Particle Attribution' [ie determinism] rule.)

Currently XSD 1.1 is supported by (in alpha order) Altova, Saxon, and Xerces.