Xsi: type restriction or restriction

Question

This is a generalized example of what I am opposed to.

I created derived types in my schema and want to create an element that is an unlimited list (sequence) that has a restriction where only two of the three derived types are allowed.

To say this from the top level, "I have events in which there can only be two types of events in one situation."

This is how I defined my events and the subsequent sequence holder. (It all works and works).

An abstract element is a complex type called "Event Base" and has a common Name attribute:

<xs:complexType name="EventBase"> <xs:annotation><xs:documentation>***Abstract Event***</xs:documentation></xs:annotation> <xs:attribute name="Name"/> </xs:complexType> 

Then I have three events stemming from the abstract, as shown below.

 <xs:complexType name="DerivedEvent1"> <xs:complexContent> <xs:extension base="EventBase"> <xs:attribute name="Alpha" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="DerivedEvent2"> <xs:complexContent> <xs:extension base="EventBase"> <xs:attribute name="Beta"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="DerivedEvent3"> <xs:complexContent> <xs:extension base="EventBase"> <xs:attribute name="Gamma"/> </xs:extension> </xs:complexContent> </xs:complexType> 

To simplify a complex object for storing derivative events, I create a specific “general” event derived from an abstract complex

 <xs:element name="Event" type="EventBase"> <xs:annotation><xs:documentation>A generic event derived from abstract.</xs:documentation></xs:annotation> </xs:element> 

Then I want to be able to hold events, so I create a new complex object to hold the “common” event shown above, but actually hold the derivative events to the potential consumer.

 <xs:complexType name="EventsCollectionType"> <xs:annotation><xs:documentation>Holds derived events</xs:documentation></xs:annotation> <xs:sequence> <xs:element ref="Event" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> 

Finally, I create an element derived from a collection type that will contain the actual events:

 <xs:element name="Events"><xs:annotation><xs:documentation>Concrete holder of events.</xs:documentation></xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="Event" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> 

The resulting xml is as follows:

 <?xml version="1.0" encoding="UTF-8"?> <Events xsi:noNamespaceSchemaLocation="file:///C:/StackOverflow.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Event xsi:type="DerivedEvent1" Name="D1" Alpha="Content1"/> <Event xsi:type="DerivedEvent3" Name="D1" Gamma="Content3"/> </Events> 

---

So the question is, how can I create a final * * * event element that will only contain specific xsi: typed elements?

Thus, in the case where a restriction has been established, only valid types 1 and 3 (as indicated above); but if he had a derived type 2, that would be wrong.

I created a public GIST ( Limit or Limit on xsi: type )

Answer 1

Maybe I'm wrong, but I do not think it is possible.

In the Events collection, you essentially want to have different structures, but all with the same Event element name. This contradicts the fundamental limitation of the schemes: http://www.w3.org/TR/xmlschema-1/#cos-element-consistent . Using xsi: type gives the schema processor a hint that will allow him to eliminate this choice of structures, while avoiding breaking this rule. This is essentially a workaround.

Could you name different things, so do you have a collection of "event1" and "event3" or an external collection containing a sequence of optional "event1" and "event3"? It would be much easier to implement the circuit in this way. In addition, you will not need to use xsi: type at all. I'm not sure what you're using xsi: type in your instances to try to get around this limitation or for some other reason, but it might be easier if someone using the schema should not worry about derived types.

Alternatively, you can use another technology (such as a schematron) to enforce this restriction.