The best way to illustrate my question is by posting some snippets of the xsd I currently have; it'll make it easier for you to make sense of my question.
Here's some snippets of my current xsd file:
<xs:element name="RiskAnalysis">
<xs:complexType>
<xs:sequence>
<xs:element ref="RiskRating" maxOccurs="unbounded"/>
</xs:sequence>
...
...
</xs:complexType>
</xs:element>
<xs:element name="RiskRating">
<xs:complexType>
...
<xs:attribute name="RatingType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="LocationNeighbourhood"/>
<xs:enumeration value="Land"/>
<xs:enumeration value="Improvements"/>
<xs:enumeration value="Environmental"/>
<xs:enumeration value="MarketSegment"/>
<xs:enumeration value="ReducedValue"/>
<xs:enumeration value="RecentMarket"/>
<xs:enumeration value="LocalEconomy"/>
<xs:enumeration value="MarketVolatility"/>
<xs:enumeration value="Other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
...
</xs:complexType>
</xs:element>
The issue I'm having is that I need to restrict my xsd such that I create an XOR for the RiskRatings between elements where RatingType is ReducedValue and RecentMarketValue, but I can't think of a way to do this.
It's best described by example, thus here's some sample RiskAnalysis elements (in xsd pseudo code) I might receive:
Acceptable (ie. neither of ReducedValue or RecentMarket passed in):
<RiskAnalysis>
<RiskRating RatingType="Land" />
<RiskRating RatingType="Other" />
</RiskAnalysis>
Acceptable (ie. only ReducedValue passed in):
<RiskAnalysis>
<RiskRating RatingType="Land" />
<RiskRating RatingType="Other" />
<RiskRating RatingType="ReducedValue" />
</RiskAnalysis>
Acceptable (ie. only RecentMarket passed in):
<RiskAnalysis>
<RiskRating RatingType="Land" />
<RiskRating RatingType="Other" />
<RiskRating RatingType="RecentMarket" />
</RiskAnalysis>
Unacceptaple and should throw a schema validation error (ie. both RecentMarket and ReducedValue passed in):
<RiskAnalysis>
<RiskRating RatingType="Land" />
<RiskRating RatingType="Other" />
<RiskRating RatingType="RecentMarket" />
<RiskRating RatingType="ReducedValue" />
</RiskAnalysis>
Anybody got any idea how I would do this?
Its not possible with XSD (alone)!!
workaround solution: You many need to use HOST CODE to evaluate this part only. The host program which is invoking XSD validation like C#, CPP, JAVA, etc ... are capable of validating these kind of conditions.
The simplest way would be to eliminate the inconsistency in the analysis of your domain implicit in your schema: on the one hand, you want risk ratings of type RecentMarket and of type ReducedValue to be treated differently for purposes of validation, while on the other hand you are giving them the same element type, which says implicitly that for purposes validation they should be treated the same. The same? or different? Choose.
Given element types RecentMarketRating, ReducedValueRating, and OtherRiskRating, it's trivial to solve your problem. Given an XML encoding which calls them all the same thing, you main options are non-XSD code to do the validation, XSD 1.1 and the use of conditional type assignment or assertions, or Schematron in addition to your XSD 1.0.
Related
I am developing an XSD document to validate XML Import files. Nearly all elements of the import file 'can' have an ID attribute (UPDATE). The UPDATE attribute must be limited to 4 possible values, so I have this pre-set type to use for the attribute restriction...
<xs:simpleType name="MyUpDir">
<xs:restriction base="xs:string">
<xs:enumeration value="OVERWRITE"/>
<xs:enumeration value="ADDONLY" />
<xs:enumeration value="NOERASE" />
<xs:enumeration value="IGNORE" />
</xs:restriction>
</xs:simpleType>
In addition to the attribute restrictions, each element's value is limited by a variety of pre-set custom types
Example:
<xs:simpleType name="MyChar50">
<xs:restriction base="xs:string">
<xs:maxLength value="50" />
</xs:restriction>
</xs:simpleType>
To combine the two, I know I can do it in-line for each element as follows:
<xs:element name="FullName">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="MyChar50">
<xs:attribute name="UPDATE" type="MyUpDir" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
The problem is that there are over 1000 elements in the import file, each having varying length/regEx/precision restrictions (roughly 20 custom types) as well as have the potential for the UPDATE attribute. Without the UPDATE attribute, I could do each element on its own line by using the custom types, greatly reducing the 'content' portion of the XSD. But from what I've read, it appears that to accomodate the custom types AND the potential for the attribute mentioned, I'm forced to use the expanded sample (last example) instead of being able to retain a single line for each such element. Is there not a way to minimize this further by creating a custom type that combines the two?
I would think that you could do 20 custom types more (for a total of 40) and then use the appropriate ones (w/ or w/o attribute). In your case:
<xs:complexType name="MyChar50Attr"><!-- This one has attributes -->
<xs:simpleContent>
<xs:extension base="MyChar50">
<xs:attribute name="UPDATE" type="MyUpDir"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="FullName" type="MyChar50Attr"/>
I'm trying to define an element type in XSD, for which i want an optional attribute, which if present can either contain a float, or be empty (but still present).
i.e:
<xs:element name="MyElement">
<xs:complexType>
<xs:attribute name="optionalFloatAttribute" type="xs:float" use="optional"/>
</xs:complexType>
</xs:element>
Needs "fixing" to allow all of the following xml:-
<MyElement/>
or
<MyElement optionalFloatAttribute=""/>
or
<MyElement optionalFloatAttribute="3.14159"/>
The only way I can see of doing this is to change type to xs:string, and use xs:restriction with a regular expression. But this doesn't seem very ideal to me. Is there a better way?
And I have to be able to support these variations of the xml - the program and existing xml is legacy, and I am trying to back-create a schema to match the myriad variations I see in what we have to regard as valid xml.
You can define custom type for that by combining float and empty string:
<xs:element name="MyElement">
<xs:complexType>
<xs:attribute name="optionalFloatAttribute" type="emptyFloat" use="optional"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="emptyFloat">
<xs:union>
<xs:simpleType>
<xs:restriction base='xs:string'>
<xs:length value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base='xs:float'>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
Or using regExp:
<xs:simpleType name="emptyFloat">
<xs:restriction base="xs:string">
<xs:pattern value="-?\d*\.?\d*"/>
</xs:restriction>
</xs:simpleType>
If you could stand using an element rather than an attribute you could make the xs:float nillable. This way you can use the xsi:nil="true" in your instance document to indicate that the element has no value:
<!-- definition -->
<xs:element name="quantity" type="xs:float" nillable="true" />
<!-- instance -->
<quantity xsi:nil="true" />
No equivalent for attributes though.
I don't think there's a way to handle this and use xs:float. Fundamentally it comes down to the fact that empty string isn't a valid number. You'd either normally expect a value of 0, or for the element to be missing altogether. There's a good explanation as the answer to the following question:
Empty elements for primitve datatypes forbidden in XSD
It seems that the option of using xs:string and a regexp might be your best plan.
Is there a way to define a constant value and use that constant in the preceeding XSD? I have a common value I want to use for various xs:element tag's maxOccurs attributes. Like constants in other languages, I want to make the change in one place should the value backing MyConst were to ever change.
<!-- Can I do this? -->
<ConstantValue id="MyConst" value="10"/>
...
<xs:element name="sandwich_meat" type="xs:string" minOccurs="0" maxOccurs="MyConst"/>
<xs:element name="sandwich_name" type="xs:string" minOccurs="0" maxOccurs="MyConst"/>
You can try to define a simpleType with a restriction:
<xs:simpleType name="AConstantHere">
<xs:restriction base="xs:string">
<xs:enumeration value="CONSTANT_VALUE_HERE"/>
</xs:restriction>
</xs:simpleType>
It allows only one value.
No it is not allowed that way. However you can define your own type with a fixed value in it somewhere on top of your XSD (place dosen matters) and use that type for the elements.
It's not possible with plain schema, but maybe XML entities will do the trick?
I have some XML documents over which I have no control whatsoever. Their structure is well-defined, but it is described in a bunch of PDFs, which, despite being very exact, don't make automated validation very tractable. I'm trying to write a XML schema to make (most of) the rules in those PDFs executable.
All the elements are mandatory. But about half of them can be either empty or have simple typed content.
When defining datatypes for these elements, I defined two versions of each: a "normal" one, and another that can be empty. I did this by defining unions with an empty datatype:
<xs:simpleType name="empty">
<xs:restriction base="xs:string">
<xs:length value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="codPostal">
<xs:restriction base="xs:string">
<xs:pattern value="^[0-9]{4}-[0-9]{3}$"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="opt_codPostal">
<xs:union memberTypes="empty codPostal"/>
</xs:simpleType>
Is there a less repetitive way of doing this?
You can use xs:nillable.
In XSD
<xs:simpleType name="codPostal">
<xs:restriction base="xs:string">
<xs:pattern value="^[0-9]{4}-[0-9]{3}$"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="OptionalString" type="codPostal" nillable="true" />
In Document
<OptionalString xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />
This is most useful for non-string types (e.g. datetime etc) as for strings you could just use zero length.
<OptionalString />
Unfortunately you need to specify the "nil" attribute on the document. As far as I know, the only non-intrusive way to do what you want is the union type approach that you've already chosen.
I have seen XML Schema element with attributes containing only text but I have an element that's an xs:dateTime instead.
The document I'm trying to write a schema for looks like this:
<web-campaigns>
<web-campaign>
<id>1231</id>
<start-at nil="true"/>
</web-campaign>
<web-campaign>
<id>1232</id>
<start-at>2009-08-08T09:00:00Z</start-at>
</web-campaign>
</web-campaigns>
Sometimes the xs:dateTime element has content, sometimes it doesn't.
What I have so far (which doesn't validate yet) is:
<xs:element name="start-at">
<xs:complexType mixed="true">
<xs:simpleContent>
<xs:extension base="xs:dateTime">
<xs:attribute name="nil" default="false" type="xs:boolean" use="optional" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
If I replace xs:dateTime with xs:string, I can validate the document just fine, but I really want an xs:dateTime, to indicate to consumers what's in that element. I tried with/without mixed="true" as well, to no avail.
If it makes a difference, I validate using xmllint (on Mac OS X 10.5) and XML Schema Validator
you can define your own types as union of types.
1/ define the "empty" type as a string that only allows "" ähm nothing :)
<xs:simpleType name="empty">
<xs:restriction base="xs:string">
<xs:enumeration value=""/>
</xs:restriction>
</xs:simpleType>
2/ next define a type that allows date AND empty
<xs:simpleType name="empty-dateTime">
<xs:union memberTypes="xs:dateTime empty"/>
</xs:simpleType>
3/ declare all your nullable datetime elements as type="empty-dateTime"
You need
<xs:element name="start-at" minOccurs="0">
mixed-mode isn't relevant to your situation, you don't need that. By default, minOccurs="1", i.e. the element is mandatory.
With minOccurs="0", you either specify the element with content, or not at all. If you want to be able to permit <start-at/>, then you cannot use xs:dateTime.