why some schemas use <xsd:choice> instead of <xsd:enumeration>? - xsd

I saw an xml schema ( EPP ) whitch used xsd:choice with an element even if we can use xsd:enumeration instead :
<element name="access" type="epp:dcpAccessType"/>
<complexType name="dcpAccessType">
<choice>
<element name="all"/>
<element name="none"/>
<element name="null"/>
<element name="other"/>
<element name="personal"/>
<element name="personalAndOther"/>
</choice>
</complexType>
to make the question clear , I will use this example instead :
<element name="sport" type="sportType"/>
<!-- using choice-->
<complexType name="sportType">
<choice>
<element name="football"/>
<element name="tennis"/>
</choice>
</complexType>
<!-- Or using enumeration-->
<simpleType name="sportType">
<restriction base="string">
<enumeration value="football"/>
<enumeration value="tennis"/>
</restriction>
</simpleType>
an xml example using that schema :
<!--using choice-->
<sport>
<football/>
</sport>
<!--using enumeration-->
<sport>football</sport>
why they prefer xsd:choice instead of xsd:enumeration in this situation ?
Thanks

Choice is for choice between elements, while enumeration allow choice between a set of values. The values can be string like in your example, but if you wanted to enumerate several element objects, then you would have to use choice.

why they prefer xsd:choice instead of xsd:enumeration in this situation ?
Presumably they want a tag instead of text content in the supported xml.
The decision to use one or the other is pretty much a matter of xml you want to support, as they do quite different things. Which xml form is preferable is quite subjective.
See also this related question.

Related

How can I define an attribute which can contain *either* an IDREF or a string enumeration?

I've made a simple UI definition language for a project and now want to create a schema, for ease of validation. Unfortunately, my XSD skills are quite rusty, and I find myself trying to so something that I'm not even certain is possible.
The UI is made up of "blocks" which can be positioned in relation to one another. In order to simplify the most common use cases, I'd like the referencing attribute to be able to contain any of the strings parent, previous, or next. In order to be as flexible as possible, I'd also like it to be able to point to any element with an ID.
In other words, I'd like the following to be valid:
<ui>
<block id="foo"/>
<block/>
<block anchor="previous"/>
<block anchor="#foo"/>
</ui>
How can I describe this in XSD?
As it turns out, XSD contains a feature which does exactly this — combines two or more types — and I had simply missed it. A union creates a type whose lexical space covers the lexical spaces of all of its member types (in other words, it can contain a value matching any of its subtypes).
With the caveat that IDREFs cannot contain a leading # (it's a direct reference to an ID, not a fragment identifier for a URL), the following schema will validate the example XML. The interesting bits are AnchorType and TreeReferenceType.
<schema targetNamespace="urn:x-ample:ui" elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ui="urn:x-ample:ui">
<element name="ui" type="ui:UIType"/>
<complexType name="UIType">
<sequence>
<element minOccurs="1" maxOccurs="unbounded" name="block" type="ui:BlockType"/>
</sequence>
</complexType>
<complexType name="BlockType">
<attribute use="optional" name="id" type="ID"/>
<attribute name="anchor" type="ui:AnchorType"/>
</complexType>
<simpleType name="AnchorType">
<union memberTypes="ui:TreeReferenceType IDREF"/>
</simpleType>
<simpleType name="TreeReferenceType">
<restriction base="string">
<enumeration value="parent"/>
<enumeration value="previous"/>
<enumeration value="next"/>
</restriction>
</simpleType>
</schema>

Explanation of target namespaces in Xml schema?

For example, let us say we have the following schema (listed in http://www.w3.org/TR/xmlschema-0/#NS)
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:po="http://www.example.com/PO1"
targetNamespace="http://www.example.com/PO1"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">
<element name="purchaseOrder" type="po:PurchaseOrderType"/>
<element name="comment" type="string"/>
<complexType name="PurchaseOrderType">
<sequence>
<element name="shipTo" type="po:USAddress"/>
<element name="billTo" type="po:USAddress"/>
<element ref="po:comment" minOccurs="0"/>
<!-- etc. -->
</sequence>
<!-- etc. -->
</complexType>
<complexType name="USAddress">
<sequence>
<element name="name" type="string"/>
<element name="street" type="string"/>
<!-- etc. -->
</sequence>
</complexType>
<!-- etc. -->
</schema>
Can you explain what the purpose of each of the attributes in the "schema" node mean? I have been trying to wrap my head around it, but I don't get it. Please correct me if I am wrong:
I assume xmlns="http://www.w3.org/2001/XMLSchema" refers to elements & attributes that have no prefix.
xmlns:po="http://www.example.com/PO1" seems like it means that anything prefixed with po, refers to this url (example.com/p01).
I don't understand what targetNamespace is for. I also don't understand what qualified or unqualified means.
This is a bit of a terminology minefield, but essentially, xmlns="http://www.w3.org/2001/XMLSchema" and xmlns:po="http://www.example.com/PO1" are there to declare namespaces for the schema document itself. Remember, an XML Schema is just an XML document, and it needs to declare the namespaces it uses just like any other XML document.
targetNamespace is used to define the namespace of the schema's instance documents, i.e. the documents which will conform to your schema. Such documents would declare their namespace to be http://www.example.com/PO1, with whatever prefix they choose e.g. they could use xmlns="http://www.example.com/PO1" or xmlns:po="http://www.example.com/PO1"

The Semantics of XML Schema Extension

Intuitively, "extension" means add something to base type, not to modify base type. The following XSD
<complexType name="B">
<attribute name="A1" type="int" use="required" />
<anyAttribute namespace="##other" processContents="strict" />
</complexType>
<complexType name="D">
<complexContent >
<extension base="tns:B">
<!--???-->
<attribute name="A1" type="int" use="optional" />
<anyAttribute namespace="##other" processContents="lax" />
</extension>
</complexContent>
</complexType>
should not compile. But XML Schema compiler(System.Xml.Schema.XmlSchema) do not throw errors. What's the rational of this counter-intuition design?
There is a problem with the Schema:
In D, you are trying to add attribute A1 a second time.
Listing something in the extension adds it to the definition. In this case "A1" is already there. Any extended instance needs to be a valid instance of the base. If A1 were not present it would not be a valid member of the base.
It looks like you need to restrict the B type if you want to make it optional.

XSD schema abstract type problem

I have a problem with an xsd schema file.
I have this abstract complex type on my schema:
<complexType name="Action" abstract="true">
<sequence>
<element name="actionType">
<complexType>
<choice>
<element name="ALARMACTION"/>
<element name="REPORTDATAACTION"/>
<element name="ENABLEOBSERVATIONACTION"/>
<element name="DISABLEOBSERVATIONACTION"/>
<element name="SETOBSERVATIONSCHEDULEACTION"/>
<element name="VERIFYOVERTIMEACTION"/>
</choice>
</complexType>
</element>
</sequence>
</complexType>
This is a concrete implementation of Action abstract element:
<complexType name="AlarmAction">
<complexContent>
<extension base="ref:Action">
<sequence>
<element name="alarmCode" type="integer"/>
<element name="report" type="string"/>
</sequence>
</extension>
</complexContent>
</complexType>
This element references the abstract Action element:
<complexType name="Conclusion">
<sequence>
<element minOccurs="0" name="observationSet" type="ref:ObservationSet"/>
<element name="action" type="ref:Action"/>
</sequence>
</complexType>
I got an error with this xml instance:
<Conclusion>
<observationSet>
<observationPhenomenum>HIGH_HEARTBEAT</observationPhenomenum>
</observationSet>
<action>
<actionType>
<ENABLEOBSERVATIONACTION></ENABLEOBSERVATIONACTION>
</actionType>
<observationId>1</observationId>
<observationId>2</observationId>
</action>
</Conclusion>
The error on netbeans is this: cvc-type.2: The type definition cannot be abstract for element action. [104]
Can someone help me?
I assume that the schema is valid; you do have somewhere a definition for a global element with the local name "Conclusion", and a non-abstract, complex type deriving from Action, with repeating observationId elements (e.g. XYZAction).
Your problem then is rezolved if you add xsi:type="XYZAction" as an attribute to your action element. Again, the attribute value must match the name of a non-abstract type, that derives from the abstract Action.
My advice to you is when in doubt, use a tool to generate a sample XML for the scenario you have in mind. I am using QTAssistant, since it allows me to easily build any scenario imaginable using simple drag and drop of XML Schema elements.
You can use an abstract complexType as element type, but the user writing a XML instance document with this schema has to state the type of the element.
For your example this means you have to write it as follows:
<Conclusion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="conclusion.xsd">
<observationSet>
<observationPhenomenum>HIGH_HEARTBEAT</observationPhenomenum>
</observationSet>
<action xsi:type="AlarmAction">
<actionType>
<ENABLEOBSERVATIONACTION></ENABLEOBSERVATIONACTION>
</actionType>
<alarmCode>10</alarmCode>
<report>Whatever</report>
</action>
</Conclusion>
For more information hav a look here: http://pic.dhe.ibm.com/infocenter/wci/v6r0m0/index.jsp?topic=%2Fcom.ibm.websphere.cast_iron.doc%2Fmap_Selecting_a_Substitution_Type.html
While validation of request xml against wsdl you have to include following attributes
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" use this in the root element
on abstract type element
<abstractElement name="XYZ" xsi:type="Name of your instance" > </abstractElement>

Disallow an element to be a child of itself in XML Schema

Im writing a XML schema for a project. I cannot solve following problem:
A element cannot be nested by itself, ex:
<document>
<text>
<b>
<i>
<a link="http://wikipedia.org">
<b />
</a>
</i>
</b>
</text>
</document>
This example shouldn't be allow because the b is nesting itself. So my question for you is: "Is it possible to disallow a element to nest it self, and if yes whats the procedure to do the trick?"
Thx in advantage!
\Morten Møller
Edit:
Until now I only have made sure that a element can be a child of itself, but not that a element cant have a descendant that is itself.
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://cs.au.dk/dWebTek/WikiXML"
targetNamespace="http://cs.au.dk/dWebTek/WikiXML"
elementFormDefault="qualified">
<element name="wiki">
<complexType>
<choice maxOccurs="unbounded">
<!-- A lot of other element is listed here -->
<element name="bold" type="xs:boldnest"/> <!-- Missing nest function -->
</choice>
<complexType>
</element>
<complexType name="boldnest">
<choice maxOccurs="unbounded">
<element name="bold" minOccurs="0" maxOccurs="0" type="xs:boldnest"/>
<!-- All the other element is copy pasted in here -->
</choice>
</complexType>
What you are trying to do is not possible. In XML Schema, if you are using a type-based approach, you can only control the children of an element through the content model, not all possible descendants.
The only way you could possibly get close to what you are trying to do is to fully define the contents of document down to the last level. But you cannot establish a recursive structure and then put in place the sort of constraint you are thinking of.
You will need to validate this using some other mechanism, after XML schema validation is done.

Resources