Is this possible to do with XSD?

[pavankumard]

Hi,The sample XML document is as follows:<Document> <Type>4</Type> <Name/> <Age/> <Location/></Document>I need to validate the document using XSD. The constriant here is if Type = 4 then it should have all the <Name>, <Age>, <Location> elements.if Type = 3 then it should have only <Location> element.Can we write an XSD for this?Thanks in advance.Pavan.

[boen_robot]

No. Schema 1.0 can't define this. Schema 1.1 (a current W3C working draft) is primary focusing on solving this issue without breaking any compatability with Schema 1.0.If you really need this functionality from your XML, what you can do is to define different elements, each carring the appropriate childs. For example

<complete><Name/><Age/><Location/></complete>

and

<short><Location/></short>

In this case, I've used the complete and short elements. Defining those two, carring their respective children (as refs) and make a choise between them would be easy.

[eight968]

You can't define those rules in the XSD, but you can just make the "name" and "age" elements optional, so your schema would validate independent of type. Alternatively, there are some work-arounds on the design front. You can create an abstract schema type with two types under it (one with name, age, location : the other with just location). Or depending how the name/age/location schema relates to the location schema, you may want to have the name/age/location schema extend from the simple location/schema. --Charles

[boen_robot]

You can't define those rules in the XSD, but you can just make the "name" and "age" elements optional, so your schema would validate independent of type.

I don't see a point. The idea is to create constrains after all.

Alternatively, there are some work-arounds on the design front. You can create an abstract schema type with two types under it (one with name, age, location : the other with just location).

Interesting... how? Any samples on this? I mean, I don't see it described in the Schema tutorial on W3Schools.

[eight968]

Type3: LocationType4: Name, Age, LocationOption 1: (just make them optional)It is sometimes better to have a simple schema than a complex and restricted one. I tend to agree that it's not the best choice from a design choice, but in larger projects, it can lead to some horrible schema bloat.Option 2:<element name="Base" type="BaseType" /><complexType name="BaseType" abstract="true" /><complexType name="Type3"> <complexContent> <extension base="BaseType"> <sequence> <element name="Location" /> </sequence> </extension> </complexContent></complexType><complexType name="Type4"> <complexContent> <extension base="BaseType"> <sequence> <element name="Name" /> <element name="Age" /> <element name="Location" /> </sequence> </extension> </complexContent></complexType>-- Sample xmlNow what we have is:<Base xsi:type="Type4"> <Name /> <Age /> <Location /></Base><Base xsi:type="Type3"> <Location /></Base>Now some invalid xml are: <!-- since it is abstract, it cannot be instantiated, thus the need for xsi:type --><Base /><!-- if it is of Type4, then it should have a name and age. A xml parser would catch this --><Base xsi:type="Type4"> <Location /></Base>Option 3: (very similar to above)<element name="Base" type="BaseType" /><complexType name="BaseType" abstract="true" /><complexType name="Type3"> <complexContent> <extension base="BaseType"> <sequence> <element name="Location" /> </sequence> </extension> </complexContent></complexType><complexType name="Type4"> <complexContent> <extension base="Type3"> <sequence> <element name="Name" /> <element name="Age" /> </sequence> </extension> </complexContent></complexType>Here we basically treat Type4 as a child of Type3 instead of having them be independent in Option 2.The only downside is the ugliness of the xsi:type. However, it's not that much more ugly than just having a type element.