In the following schema I am trying to make an unordered xml that extends simpleConfigurationObject:
<xs:complexType name="forTestingConfigurationObjectCreator">
<xs:complexContent>
<xs:extension base="simpleConfigurationObject">
<xs:all>
<xs:element name="a" type="xs:string"/>
<xs:element name="b" type="xs:string" minOccurs="0"/>
</xs:all>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="simpleConfigurationObject">
<xs:all>
<xs:element name="base" type="xs:string" minOccurs="0"/>
</xs:all>
</xs:complexType>
But I get the following error on the xs:all
"all is not the only particle in the group, or is being used as an extension" (which is correct)
Off-course if put the base element inside the xs:all and not use xs:extension at all I will get an unordered schema restriction. (but that is not what I want)
The question is: how can I produce unordered schema with the extension?
Thanks
You can't, this is prohibited by the schema specification. See this post of Henry Thompson (the author of the spec) for an explanation.
In short: the content model of the base type has to be completely parsed by the time the parser gets to the derived type; that is not possible with what you are trying to achieve.
Related
I have the following XSD structure:
<xs:schema xmlns:ns="http://abc/">
...
<xs:element name="abc">
<xs:complexType>
<xs:sequence>
<xs:element ref="map"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
<xs:element name="map">
<xs:complexType>
<xs:sequence>
<xs:element name="entry" type="ns:MapEntryType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:unique name="entry">
<xs:selector xpath="entry"/>
<xs:field xpath="key"/>
</xs:unique>
</xs:element>
<xs:complexType name="MapEntryType">
<xs:sequence>
<xs:element name="key" type="xs:string"/>
<xs:element name="value" type="xs:anyType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
This is doing its job.
The map element now has to be called something different based on whichever is the wrapper, so the name is sometimes map, sometimes properties, sometimes options, etc.
Therefore I want to genericize the map element.
I tried doing the following:
Making map a xs:complexType and changing ref to type.
This resulted in xs:unique not being accepted and failed
Making map a xs:complexType, changing ref to type and moving the xs:unique constraint to the element definitions.
This worked but resulted in the XSD having a lot of xs:unique present in the document.
Isn't there a way to simply tell that I want a specific structure and it containing unique elements without having to repeat the unique constraint everywhere?
As Petru Gardea said in his answer
Both XSD 1.0 and 1.1 place the identity constraints under an element
So you have to add xs:unique to every element, but if you are using XSD 1.1 you can define only once a complete xs:unique and then in the rest of the elements use xs:unique ref="name". This is not valid for you as you are using XSD 1.0, but I let it here for future XSD 1.1 users that find this good question.
Example (namespaces removed for clarity):
<xs:element name="map">
<xs:complexType>
<xs:sequence>
<xs:element name="entry" type="MapEntryType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Only completely defined once -->
<xs:unique name="uniqueEntry">
<xs:selector xpath="entry"/>
<xs:field xpath="key"/>
</xs:unique>
</xs:element>
<xs:element name="hashMap">
<xs:complexType>
<xs:sequence>
<xs:element name="entry" type="MapEntryType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Referenced here and every other time -->
<xs:unique ref="uniqueEntry"/>
</xs:element>
Short answer, it is not possible. Both XSD 1.0 and 1.1 place the identity constraints under an element; a constraint cannot be globally defined, therefore there is no "reuse" per se, other than that of the enclosing element. Given your scenario (different element names for different needs) it is not possible to reuse.
How should I reference another complexType in xml, as element or as attribute over my own defined Key? What is the correct approach to model the following self-reference? Is the first approach even possible, or does it lead to infinite self-referencing?
<xs:complexType name="Category">
<xs:sequence>
<xs:element name="ParentCategory" type="Category" minOccurs="1" maxOccurs="1"></xs:element>
<xs:element name="ChildCategory" type="Category" minOccurs="0" maxOccurs="unbounded"></xs:element>
</xs:sequence>
<xs:attribute name="CategoryName" type="xs:string"></xs:attribute>
</xs:complexType>
or
<xs:complexType name="Category">
<xs:sequence>
<xs:element name="ChildCategory" type="Category" minOccurs="0" maxOccurs="unbounded"></xs:element>
</xs:sequence>
<xs:attribute name="CategoryName" type="xs:string"></xs:attribute>
<xs:attribute name="ParentCategory" type="xs:string"></xs:attribute>
</xs:complexType>
I'm a bit confused - since I want to be object oriented, but am not sure how this would look like in XML. Wouldn't the reference of ParentCategory as a Category-type require me to again write a Category-type in XML that itself has a ParentCategory child-element, etc... leading to infinite type-referencing.
There's no issue referencing an element of the same type as part of the type definition, so your first example is fine from that point of view. Trying to reference the parent is a bit odd though, you shouldn't really need to do this... XML is hierarchical after all.
<xs:complexType name="Category">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="ChildCategory" type="Category"/>
</xs:sequence>
<xs:attribute name="CategoryName" type="xs:string"/>
</xs:complexType>
The Category type references itself recursively, allowing for 0 or more ChildCategory elements. This should do what you need (there's nothing wrong with recursive type referencing in the XML Schema).
If you need to refer to the parent Category in your document, it's easy enough to chain to the parent node in any DOM implementation or with XPath.
What is the practical diference between these two:
<xs:element name="A">
<xs:complexType mixed="true">
<xs:attribute name="att" type="xs:boolean"/>
</xs:complexType>
</xs:element>
<xs:element name="B">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="att" type="xs:boolean"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
The two are different. Your first example uses mixed="true" which denotes mixed content, i.e. character data mixed in with child elements. Whereas your second example restricts the element content to the xs:string type. Both indicate the presence of an attribute.
With your example, both are practically the same. However, if you do not plan on having mixed content, i.e. you do not plan to add child elements, the second version is much clearer.
This is a part of my xml schema
<xs:complexType name="Friend">
<xs:all>
<xs:element name="name" type="xs:string" />
<xs:element name="phone" type="xs:string" />
<xs:element name="address" type="xs:string" />
</xs:all>
</xs:complexType>
<xs:complexType name="Coworker">
<xs:all>
<xs:element name="name" type="xs:string" />
<xs:element name="phone" type="xs:string" />
<xs:element name="office" type="xs:string" />
</xs:all>
</xs:complexType>
For better maintainability, I would like to have the shared attributes in an (abstract) super type or something like that. But more important, I want that all elements are unordered and also optional.
Is this possible, and what is the best way to do it?
You have to limit yourself a little bit, some of the things you are trying to do are not possible in XML Schema.
Suppose you introduce a complex type called Person to be a super-type of Friend and Coworker. Here are your options:
Replace xs:all with xs:sequence, remove name and phone from the sub-types, add to the super-type, and add inheritance. Your elements now have to be ordered, but you can make them individually optional. It is illegal to use xs:all in type hierarchies in XML Schema, because the processor cannot tell where the parent content model stops and the child content model starts.
Replace xs:all with <xs:choice maxOccurs="unbounded"> in both types, and add your inheritance. Then your elements become unordered again, but they may repeat.
So in conclusion: given your type names up there, I would guess that your requirements will not be exactly met. I would go for the first option: insisting on arbitrary element order is often not as useful as it seems.
One-and-half year after this question and the accepted answer were posted, XSD 1.1 was published. In this version it is possible to specify what the OP asked for because a number of restriction on xs:all were lifted. One of them is that it is now possible to extend an xs:all.
Using XSD 1.1 you can specify the following:
<xs:complexType name="Person" abstract="true">
<xs:all>
<xs:element name="name" type="xs:string" minOccurs="0" />
<xs:element name="phone" type="xs:string" minOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="Friend">
<xs:complexContent>
<xs:extension base="Person">
<xs:all>
<xs:element name="address" type="xs:string" minOccurs="0" />
</xs:all>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Coworker">
<xs:complexContent>
<xs:extension base="Person">
<xs:all>
<xs:element name="office" type="xs:string" minOccurs="0" />
</xs:all>
</xs:extension>
</xs:complexContent>
</xs:complexType>
This defines the following types:
Person: an abstract type with optional unordered name and phone elements;
Friend: extends Person adding an optional address element to the list of unordered elements;
Coworker: extends Coworker adding an optional office element to the list of unordered elements.
Note that this solution does not work for every XML processor: even though 8 years have passed since the publication of XSD 1.1, a lot of processors still only support XSD 1.0.
I've inherited the task of creating a schema for some XML which already exists - and IMHO is not the best that could have been done. The section giving me problems is the element at the end of the 'scan-result' element.
The best I'm hoping for with regard to the data in the 'spectrum' element is to treat it as type="xs:string". I'll programatically divide up the numeric pairs that constitute the data in the string later. (Even though this step would not be needed had the data been properly structured in the first place.)
Here's a similar piece of XML data to what I have to work with...
<scan-result>
<spectrum-index>0</spectrum-index>
<scan-index>2</scan-index>
<time-stamp>5609</time-stamp>
<tic>55510</tic>
<start-mass>22.0</start-mass>
<stop-mass>71.0</stop-mass>
<spectrum count="5">30,11352;31,360;32,16634;45,1161;46,26003</spectrum>
</scan-result>
The problem is, I can't seem to get a working definition for the 'spectrum' element that has the 'count' attribute and allows me to define the 'spectrum' element type as "xs:string".
What I would like is something like the following:
<xs:complexType name="ctypScanResult">
<xs:sequence>
<xs:element name="spectrum-index" type="xs:integer"/>
<xs:element name="scan-index" type="xs:integer"/>
<xs:element name="time-stamp" type="xs:integer"/>
<xs:element name="tic" type="xs:integer"/>
<xs:element name="start-mass" type="xs:float"/>
<xs:element name="stop-mass" type="xs:float"/>
<xs:element name="spectrum" type="xs:string">
<xs:complexType>
<xs:attribute name="count" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="count" type="xs:integer"/>
</xs:complexType>
The problem is that I can define the type of the 'spectrum' element as "xs:string" XOR I can define the anonymous 'xs:complexType' in the 'spectrum' element, which allows me to insert the 'count' attribute. But I need to be able to express both.
Given that I'm kind of stuck with the XML as it was handed to me, is there a schema definition that will allow me to describe this data?
Sorry this is long, but thanks to any and all who respond,
AlarmTripper
Followup: I know why the error occurs...
Quoted from W3C:
3.3.3 Constraints on XML Representations of Element Declarations
Schema Representation Constraint: Element Declaration Representation OK
In addition to the conditions imposed on element information items by the schema for schemas: all of the following must be true:
1 default and fixed must not both be present.
2 If the item's parent is not , then all of the following must be true:
2.1 One of ref or name must be present, but not both.
2.2 If ref is present, then all of , , , , , nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with .
3 type and either or are mutually exclusive.
4 The corresponding particle and/or element declarations must satisfy the conditions set out in Constraints on Element Declaration Schema Components (§3.3.6) and Constraints on Particle Schema Components (§3.9.6).
But I'm still in the same fix I was before... How can I actually accomplish something that resembles my goal?
Thanks,
AlarmTripper
Let a tool do it for you! Try xsd.exe.
Or, if you must define by hand, at least check your hand-written-definition with an automatically generated one.
Here's what XSD.exe gave me for your input. I trimmed out some MS-NS cruft.
<xs:element name="spectrum">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="count" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
You need to set the attribute mixed="true" on complexType:
<xs:element name="spectrum">
<xs:complexType mixed="true">
<xs:attribute name="count" type="xs:integer" />
</xs:complexType>
</xs:element>
EDIT: Okay, just read your comment, sorry. I believe the following should work instead:
<xs:element name="spectrum">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="count" type="xs:integer" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="spectrum" type="xs:string">
<xs:complexType>
<!-- ADD THIS NEXT LINE -->
<xs:complexContent mixed="true"/>
<xs:attribute name="count" type="xs:integer"/>
</xs:complexType>
</xs:element>