Can you have more than one indicator in an XSD complex element? - xsd

I'm trying to build a new schema to validate XML against for my job. But I'm having a hard time answering the question: can I and how do I create a complex element that has some elements that need to be in a set sequence and other subelements that do not? Ultimately I think I should be able to have opening and closing "sequence" tags and opening and closing "all" tags around two sets of elements, but xsd doesn't seem to like that. Here's what I have:
<xsd:complexType name="Original">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="AssetIdentifier" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Definition: The Asset Identifier element is intended to
reflect the root of all following digital filenames.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="ArchiveID" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Definition: The Filename element in this section is
intended to reflect the root of all the following derivative digital
filenames.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="1" name="Title" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Definition: The known title of the asset. If no title is
known, one can be assigned; a number or letter sequence, whichever is
the most logical. Using the value "unknown" is also
acceptable.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="1" name="RecordDate" type="xsd:date">
<xsd:annotation>
<xsd:documentation>Definition: The actual recording date of the asset.
Estimates, partial dates, and date ranges (i.e. 19XX, Feb. 19-24,
1934-1935, etc.) are allowable, as is 'unknown'. Best practice, when
applicable, is to use the YYYY-MM-DD format in accordance with ISO 8601.
Even partial dates, i.e. 1990-05 should adhere to this
format.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="1" name="FormatType" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Definition: The format of the analog asset, i.e. Open
Reel, Grooved Disc, DAT, Cassette, VHS, 16mm film, EIAJ,
etc.</xsd:documentation>
<xsd:documentation>Best Practice: The MediaPreserve maintains a list of
controlled vocabularies organized by media type at: www.dontknowyet.com.
However, MP opted to meake this an unrestricted element in the event
that other ogranizations have their own controlled vocabularies in
place.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:all>
<xsd:element maxOccurs="1" minOccurs="0" name="StockBrand" type="xsd:string">
<xsd:annotation>
<xsd:documentation>If known definitively</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="TapeModel" type="xsd:string">
<xsd:annotation>
<xsd:documentation>If applicable. Usually applies to DAT tapes, open reels,
and wire recordings.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="TapeWidth" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Typically only applicable for open reel
audio</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:all>

XSDs unfortunately do not allow what you're trying to do (combine <sequence/> and <all /> inside a single complex type or element). You might be able to achieve something similar with a nested content model, but note you can't nest <all> except under another <all />, otherwise you must define it in another element. You can however, nest either <sequence> or <choice> under each other.
From my understanding of XSDs, you have 3 viable options.
The first is to nest all the elements you want under <all /> to be contained within their own sub-element:
<xs:complexType name="Original">
<xs:sequence>
<!-- AssetIdentifier to FormatType left out for brevity -->
<xs:element name="Misc">
<xs:complexType>
<xs:all>
<xs:element maxOccurs="1" minOccurs="0" name="StockBrand" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="TapeModel" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="TapeWidth" type="xs:string" />
</xs:all>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<!-- For the above, valid XML would be: -->
<Original>
<AssetIdentifier>AssetIdentifier0</AssetIdentifier>
<Title>Title0</Title>
<RecordDate>2006-05-04</RecordDate>
<FormatType>FormatType0</FormatType>
<Misc>
<!-- Optional & order doesn't matter -->
<StockBrand>what</StockBrand>
<TapeWidth>1290</TapeWidth>
<TapeModel>Hey</TapeModel>
</Misc>
</Original>
Second is to nest those elements under another <sequence />, which allows you to forgo specifying another sub-element, but now requires the elements appear in order as specified in the schema. Note that the nested sequence itself can be optional.
<xs:complexType name="Original">
<xs:sequence>
<!-- AssetIdentifier to FormatType left out for brevity -->
<xs:sequence minOccurs="0">
<xs:element maxOccurs="1" minOccurs="0" name="StockBrand" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="TapeModel" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="TapeWidth" type="xs:string" />
</xs:sequence>
</xs:sequence>
</xs:complexType>
<!-- For the above, valid XML would be: -->
<Original>
<AssetIdentifier>AssetIdentifier0</AssetIdentifier>
<Title>Title0</Title>
<RecordDate>2006-05-04</RecordDate>
<FormatType>FormatType0</FormatType>
<!-- Optional below, but must be ordered -->
<StockBrand>what</StockBrand>
<TapeModel>Hey</TapeModel>
<TapeWidth>1290</TapeWidth>
</Original>
There's a third option that is a bit of a 'hack', but still allows specifying elements go unordered, still remain optional, yet still appear adjacent to the other mandatory, in-order elements. This nests a choice (with maxOccurs="3") under sequence, inside the parent sequence (sequence > sequence > choice):
<xs:complexType name="Original">
<xs:sequence>
<!-- AssetIdentifier to FormatType left out for brevity -->
<xs:sequence>
<xs:choice maxOccurs="3" minOccurs="0">
<xs:element name="StockBrand" type="xs:string"/>
<xs:element name="TapeModel" type="xs:string"/>
<xs:element name="TapeWidth" type="xs:string"/>
</xs:choice>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<!-- For the above, valid XML would be: -->
<Original>
<AssetIdentifier>AssetIdentifier0</AssetIdentifier>
<Title>Title0</Title>
<RecordDate>2006-05-04</RecordDate>
<FormatType>FormatType0</FormatType>
<!-- Optional, unordered, but there's a catch: -->
<TapeWidth>1290</TapeWidth>
<StockBrand>what</StockBrand>
<TapeModel>Hey</TapeModel>
</Original>
There's a catch with this 3rd option however, the maxOccurs="3" on the <choice /> element renders the minOccurs and maxOccurs on the child elements (StockBrand, TapeModel and TapeWidth) meaningless; which means those elements, while still remaining optional, can now appear more than once, so long as the cumulative total of elements is still 3 or less:
This becomes valid (2 of the same element + 1 more):
<TapeWidth>1290</TapeWidth>
<TapeWidth>1291</TapeWidth>
<TapeModel>Hey</TapeModel>
And this is still valid (3 of the same):
<TapeWidth>1290</TapeWidth>
<TapeWidth>1291</TapeWidth>
<TapeWidth>1292</TapeWidth>
And also this (just 1 occurence of 1 element):
<StockBrand>1290</StockBrand>
You could probably try to find another option by fiddling with the combination of sequence and choice nesting, but it's best practice to keep your schemas simple. Personally I would recommend the first 2 options over the third purely to keep your schema simple.

Related

Reference the content of an element in xsd

Is it possible to reference an element in xsd, so that its content is written into another?
I think of someting like "shipping address" and "billing address".
If you choose that "billing address" is the same as "shipping address", than take the content of field "shipping address" and write it into "billing address".
I'm new to xsd/xml, so suggestions and criticism are welcome.
This is what I've got so far...
<xsd:group name="c_Shipping_Adress">
<xsd:element name="shipping_address">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Title"/>
<xsd:element name="First_Name"/>
<xsd:element name="Last_Name"/>
<xsd:element name="Street"/>
<xsd:element name="Zip"/>
<xsd:element name="City"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:group>
<xsd:group name="c_Billing_Adress">
<xsd:element name="billing_address">
<xsd:complexType>
<xsd:choice>
<xsd:element name="is_same_as_shipping_address">
<xsd:group ref="shipping_address"/>
</xsd:element>
<xsd:group name="is_not_same_as_shipping_address">
<xsd:sequence>
<xsd:element name="Title"/>
<xsd:element name="First_Name"/>
<xsd:element name="Last_Name"/>
<xsd:element name="Street"/>
<xsd:element name="Zip"/>
<xsd:element name="City"/>
</xsd:sequence>
</xsd:group>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:group>
To be honest its not very clear what your asking, and your XSD is not structured correctly, making it difficult to determine your intentions. But hopefully the following will provide enough of a basis to build on.
<?xml version="1.0" encoding="utf-8" ?>
<!--Created with Liquid Studio 2019 BETA (https://www.liquid-technologies.com)-->
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="ShippingAddress" type="AddressType" />
<xs:element name="BillingAddress" type="AddressType" />
<xs:element name="OtherAddress">
<xs:complexType>
<xs:complexContent>
<xs:extension base="AddressType">
<xs:sequence>
<xs:element name="ExtraThing" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="Title" type="xs:string" />
<xs:element name="First_Name" type="xs:string" />
<xs:element name="Last_Name" type="xs:string" />
<xs:element name="Street" type="xs:string" />
<xs:element name="Zip" type="xs:string" />
<xs:element name="City" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>

extending existing complexType

this topic is related to xsd: define an element that can be repeated an even number of times. i would like to create a new complex type using complexContent with extension. i tried this:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
<xs:complexType name="evenOccurrence">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="B" maxOccurs="2" minOccurs="2"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="oddOcurrence">
<xs:complexContent>
<xs:extension base="evenOccurrence">
<xs:sequence>
<xs:element name="B"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
this code generate the following error: cos-nonambig: B and B (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.. how i can fix the problem
This are two similar ways of doing it:
1- Without extension:
<xs:complexType name="oddOcurrence">
<xs:sequence>
<xs:element name="B" /> <!-- 1 time -->
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<!-- 2n times -->
<xs:element name="B" maxOccurs="2" minOccurs="2" />
</xs:sequence>
</xs:sequence>
</xs:complexType>
2- Similar, with extension
<xs:complexType name="elementOneTime">
<xs:sequence>
<!-- 1 time -->
<xs:element name="B" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="oddOcurrence">
<xs:complexContent>
<xs:extension base="elementOneTime">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<!-- 2n times -->
<xs:element name="B" maxOccurs="2" minOccurs="2" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
EDIT: ¿Why was it ambiguous?
As evenOccurrence can be empty, when the parser finds the first B element of and oddOccurance, it doesn't know if its parsing the first B of an evenOccurance or the B element that only appears once.
By putting first the element that can only appear once you remove the ambiguity, as the first B element would be analyzed and then the parser would enter in a state in which it would analyze the oddOccurence type (all the other B elements).

EMF: Overriding XSD

I am writing XSD to generate Model Classes using EMF.
The XSD looks like:
<xsd:complexType name="DerivedType">
<xsd:complexContent mixed="false">
<xsd:extension base="ParentType">
<xsd:sequence>
<xsd:element ...../>
<xsd:element ...../>
</xsd:sequence>
<xsd:attribute .... />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Here the DerivedType is extending from ParentType.
ParentType contains another complex element 'cmplx'.
Now, I want to add another attribute to complex element ('cmplx').
I don't want to extend 'cmplx' as it will create a new class in EMF generated code against extending the 'cmplx' type.
You can add an element or attribute defining its type as follows:
<xs:element name="name" type="xs:string"/>
<xs:attribute name="name" type="xs:string" />
Can you be more specific? What kind of attribute would you like to add? Is it an attribute or is it an element?

How to extend a choice complexType without sequencing the choice?

I have a choice complexType named abType:
<xs:complexType name="abType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="a"/>
<xs:element name="b"/>
</xs:choice>
</xs:complexType>
This type can be used to create elements with a and b nodes in any order like this for example:
<ab>
<b/>
<a/>
</ab>
Now I want to create a derived type called abcType to allow the nodes a, b and c in any order. Therefore I created a new complexType based on abType:
<xs:complexType name="abcType">
<xs:complexContent>
<xs:extension base="abType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="c"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
After that I created a abc node:
<abc>
<c/>
<b/>
<a/>
</abc>
But this node is invalid! It is not valid to put any a or b after a c. The reason is, that deriving a type from a base type creates an implicite sequence although both types are choices. XMLspy illustrates it in this way:
This result is quite useless for choice types.
So my question is: How to extend a choice type without sequencing the choice?
Here is the complete XSD and an XML test file to reproduce the problem:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element ref="ab"/>
<xs:element ref="abc"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ab" type="abType"/>
<xs:complexType name="abType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="a"/>
<xs:element name="b"/>
</xs:choice>
</xs:complexType>
<xs:element name="abc" type="abcType"/>
<xs:complexType name="abcType">
<xs:complexContent>
<xs:extension base="abType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="c"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Example:
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="inherit-choice.xsd">
<ab>
<b/>
<a/>
</ab>
<abc>
<c/>
<b/>
<a/>
</abc>
</root>
There is a way to do this that relies on the fact that a choice within a choice acts as a bigger choice.
First, define an element group which contains a single choice from all the elements within the base element:
<xs:group name="common_ab_elements">
<xs:choice>
<xs:element name="a"/>
<xs:element name="b"/>
</xs:choice>
</xs:group>
Then you can use this in your definition of abElement in place of the elements you had before:
<xs:complexType name="abType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:group ref="common_ab_elements"/>
</xs:choice>
</xs:complexType>
If you need an extended type, then you can extend the choice:
<xs:complexType name="abcType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:group ref="common_ab_elements"/>
<xs:element name="c"/>
</xs:choice>
</xs:complexType>
This is equivalent to:
<xs:complexType name="abcType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="a"/>
<xs:element name="b"/>
</xs:choice>
<xs:element name="c"/>
</xs:choice>
</xs:complexType>
And because of the nature of the choice operation, this is in turn equivalent to:
<xs:complexType name="abcType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="a"/>
<xs:element name="b"/>
<xs:element name="c"/>
</xs:choice>
</xs:complexType>
...which is what you want.
If you have attributes as well, then you may also need to define a common base class which you can extend. With this scheme, only classes with no derived classes should have elements, as it's the presence of elements on the base elements that forces the sequencing.
What we are effectively doing here is defining the inheritance of choice elements separately from the elements hierarchy itself.
Unfortunately, the short answer is NO, you can't extend a choice compositor. Logically, if there is some sort of relationship between a, b, and c (as in Java, .NET, everything is ultimately an Object, you could do the same in XSD) then I suggest the use of substitution groups instead (or, if you prefer, something based on xsi:type).
UPDATE with an example. The XSD-1:
<?xml version="1.0" encoding="utf-8" ?>
<!--W3C Schema generated by QTAssistant/W3C Schema Refactoring Module (http://www.paschidev.com)-->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="ab" type="abType"/>
<xsd:complexType name="abType">
<xsd:sequence>
<xsd:element ref="ExtensibleChoice-A" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ExtensibleChoice-A" type="ExtensibleChoiceBaseType" abstract="true" />
<xsd:complexType name="ExtensibleChoiceBaseType" abstract="true">
<xsd:sequence/>
</xsd:complexType>
<xsd:element name="a" substitutionGroup="ExtensibleChoice-A" type="aType" block="#all"/>
<xsd:element name="b" substitutionGroup="ExtensibleChoice-A" type="bType" block="#all"/>
<xsd:element name="c" substitutionGroup="ExtensibleChoice-A" type="cType" block="#all"/>
<xsd:complexType name="aType">
<xsd:complexContent>
<xsd:extension base="ExtensibleChoiceBaseType">
<xsd:sequence>
<xsd:element name="aChild" type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="bType">
<xsd:complexContent>
<xsd:extension base="ExtensibleChoiceBaseType">
<xsd:sequence>
<xsd:element name="bChild" type="xsd:int"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="cType">
<xsd:complexContent>
<xsd:extension base="ExtensibleChoiceBaseType">
<xsd:sequence>
<xsd:element name="cChild" type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
The extensibility is that at a point in time, you may have only a, b and c as members. If you, or a consumer, decide to add something (say a d element), then you simply create another schema that references the old one, with the new element d, and then use that new schema instead. The old XSD file doesn't get touched; generating new JAXB classes (as an example) will result in backward compatible code.
So, XSD-1 will validate something like this:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<ab xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tempuri.org/XMLSchema.xsd">
<a>
<aChild>aChild1</aChild>
</a>
<b>
<bChild>1</bChild>
</b>
<c>
<cChild>cChild1</cChild>
</c>
</ab>
You would need something like this (XSD-2):
<?xml version="1.0" encoding="utf-8" ?>
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema1.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema1.xsd" xmlns:b="http://tempuri.org/XMLSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://tempuri.org/XMLSchema.xsd" schemaLocation="XSD-1.xsd"/>
<xsd:element name="d" substitutionGroup="b:ExtensibleChoice-A" type="dType" block="#all"/>
<xsd:complexType name="dType">
<xsd:complexContent>
<xsd:extension base="b:ExtensibleChoiceBaseType">
<xsd:sequence>
<xsd:element name="dChild" type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
the diagram shows the "new" list of members, d is highlighted in blue:
To validate this:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<ab xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:d="http://tempuri.org/XMLSchema1.xsd">
<a>
<aChild>aChild1</aChild>
</a>
<d:d>
<d:dChild>1</d:dChild>
</d:d>
</ab>
Another example with Substitutions.
XSD
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element ref="abExtension"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="abExtension" type="abExtensionType"/>
<xs:complexType name="abExtensionType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="a"/>
<xs:element name="b"/>
</xs:choice>
</xs:complexType>
<xs:element name="abcExtension" substitutionGroup="abExtension">
<xs:complexType>
<xs:complexContent>
<xs:extension base="abExtensionType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="c"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="abcdExtension" substitutionGroup="abExtension">
<xs:complexType>
<xs:complexContent>
<xs:extension base="abExtensionType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="c"/>
<xs:element name="d"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
Sample XML's that validate with this are
abcExtension.xml
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Test.xsd">
<abcExtension>
<b></b>
<a></a>
<c></c>
</abcExtension>
</root>
abcdExtension.xml
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Test.xsd">
<abcdExtension>
<a>text</a>
<b>test</b>
<d>text</d>
<c>text</c>
</abcdExtension>
</root>
abExtension.xml
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Test.xsd">
<abExtension>
<b></b>
<a></a>
</abExtension>
</root>
If your focus is on extending rather than type inheritance, a <choice> can be extended by redefining a <group> as follows:
File "abc.xsd" containing the base schema:
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="any"
xmlns:n="any"
elementFormDefault="qualified">
<group name="baseGroup">
<choice>
<element name="a"/>
<element name="b"/>
<element name="c"/>
</choice>
</group>
<complexType name="choiceType">
<sequence minOccurs="0" maxOccurs="unbounded">
<group ref="n:baseGroup"/>
</sequence>
</complexType>
<element name="test">
<complexType>
<sequence>
<element name="sample" type="n:choiceType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
</schema>
File "abcdef.xsd" extending the <choice> defined in the base schema:
<?xml version="1.0"?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="any"
xmlns:n="any"
elementFormDefault="qualified">
<redefine schemaLocation="abc.xsd">
<group name="baseGroup">
<choice>
<group ref="n:baseGroup"/>
<element name="d"/>
<element name="e"/>
</choice>
</group>
</redefine>
</schema>
This validates the following xml file, for instance:
<?xml version="1.0" encoding="UTF-8"?>
<test
xmlns="any"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="any ../schemas/abcde.xsd">
<sample>
<a/>
<c/>
<b/>
<a/>
</sample>
<sample>
<c/>
</sample>
<sample>
</sample>
<sample>
<a/>
<e/>
<b/>
<d/>
<a/>
</sample>
</test>
Its Very Simple you can do using "choice" keyword and set its occurrence
<xs:element name="Product">
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs="1" maxOccurs="14">
<xs:element>
</xs:element>
// Post your element configuration here
</xs:choice>
</xs:sequence>
</xs:complexType>

XML Schema with complext type containing <xs:all> and <xs:any>?

I want to define a complex type that contains elements that may or may not exist, and also allows for additional undefined elements so I've got something like this:
<xs:complexType name="MyType">
<xs:sequence>
<xs:element name="A" type="xs:float" minOccurs="0" maxOccurs="1" />
<xs:element name="B" type="xs:float" minOccurs="0" maxOccurs="1" />
<xs:element name="C" type="xs:float" minOccurs="0" maxOccurs="1" />
<xs:any minOccurs="0" processContents="skip"/>
</xs:sequence>
</xs:complexType>
I don't want to force the order using <xs:sequence> so I want to change the <xs:sequence> to <xs:all> but then <xs:any> isn't allowed. Is there some way to accomplish this?
To allow any order, use this:
<xs:complexType name="MyType">
<xs:all minOccurs="1" maxOccurs="1">
<xs:element name="A" type="xs:float" minOccurs="0" maxOccurs="1" />
<xs:element name="B" type="xs:float" minOccurs="0" maxOccurs="1" />
<xs:element name="C" type="xs:float" minOccurs="0" maxOccurs="1" />
</xs:all>
</xs:complexType>
But then, you can't have an <any> inside an <all>.
Nor can you have them both inside one type, either directly or as an extension.

Resources