CODEWITHSUNDEEP
javajaxbxsd
egelev
egelev

Reputation: 1205

How to allow elements of any type in my complex type excluding the types/elements from imported schemas

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.

Upvotes: 0

Views: 193

Answers (1)

C. M. Sperberg-McQueen
C. M. Sperberg-McQueen

Reputation: 25034

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' [i.e. determinism] rule.)

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

Upvotes: 1

Related Questions