I have a following schema accepting only COM1-4.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:complexType name="Component">
<xs:attribute name="type" type="ComponentType"/>
</xs:complexType>
<xs:simpleType name="ComponentType">
<xs:restriction base="xs:string">
<xs:enumeration value="COM1"/>
<xs:enumeration value="COM2"/>
<xs:enumeration value="COM3"/>
<xs:enumeration value="COM4"/>
</xs:restriction>
</xs:simpleType>
Now the requirement has changed. I need to allow any characters(lower or uppercase). I need to make it backward-compatible with the previous values which are already populated in the production env.
I want to preserve 'ComponentType' name and enum types for ComponentType. I would like to minimize the code change. If possible, I would like to take care of it in the schema level. These COM[1-4] is just naming convention changed for this post. Actual values are different.
Is there a way to change the schema which can accept the any characters(lower or uppercase) within the scope of schema without regenerating the java artifacts or make a change on java code?
Thanks.
I think this will work, but I have no idea on the impact on your Java code:
<xs:simpleType name="ComponentType">
<xs:restriction base="xs:string">
<xs:pattern value="[cC][oO][mM][1-3]"/>
</xs:restriction>
</xs:simpleType>
Related
Is it possible to write conditional based xsd. I have list of countries defined in my xsd, If user choose country as UNITED STATES, xsd should allow user to select the states which belong to above choosen country, Else it should show validation error. Below example, perfectly allow user to select country and state for the below list, But it does not perform any validations agaist country. If you have any suggestions to write choice based xsd, Please let me know. Please note that, I have tried <xs:choice>, it does not work for this scenario.
<xs:complexType name="header-type">
<xs:sequence>
<xs:element name="country" type="country-type" />
<xs:element name="states" type="state-type" />
</xs:complextType>
<xs:simpleType name="country-type">
<xs:restriction base="xs:string">
<xs:enumeration value="UNITEDSTATES"></xs:enumeration>
<xs:enumeration value="AUS"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="state-type">
<xs:restriction base="xs:string">
<xs:enumeration value="California"></xs:enumeration>
<xs:enumeration value="Sydney"></xs:enumeration>
<xs:enumeration value="Texas"></xs:enumeration>
</xs:simpleType>
I want to do this:
XML Schema How to Restrict Attribute by Enumeration
...but I have MANY different attributes that take the exact same values. This makes my XSD very complex.
Can I define the restriction once and then reference it on each attribute somehow ???
Thanks in advance. :)
If you have many different attributes that take on the exact same values, simply reuse the attribute type definitions:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0">
<xs:simpleType name="colorType">
<xs:restriction base="xs:string">
<xs:enumeration value="red" />
<xs:enumeration value="green" />
<xs:enumeration value="blue" />
</xs:restriction>
</xs:simpleType>
<xs:element name="RoomColors">
<xs:complexType>
<xs:attribute name="wall" type="colorType"/>
<xs:attribute name="carpet" type="colorType"/>
<xs:attribute name="ceiling" type="colorType"/>
<xs:attribute name="funiture" type="colorType"/>
</xs:complexType>
</xs:element>
</xs:schema>
It's when the values are not the exact same that there's more creativity involved. See Extend enumerated lists in XML schema.
I am a beginner in XML schema and XMPP message protocols. Is there any explicit way to understand the below XML schema. What does each tags means and how many types of tags are there - what is the specified way of reading and writing them:
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/address'
xmlns='http://jabber.org/protocol/address'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0033: http://www.xmpp.org/extensions/xep-0033.html
</xs:documentation>
</xs:annotation>
<xs:element name='address'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='bcc'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='uri' use='optional' type='xs:string'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
XSD is a complex language, and there's no way of giving an adequate explanation in a few paragraphs. Reading the W3C XML Schema Primer (XML Schema Part 0) might be a good start; even better, get Eric van der Vlist's book and read the opening chapters.
The fragment you have given us is not well-formed: it contains an unmatched </xs:attribute> end tag at line 26. If we add the missing line:
<xs:attribute name='type' use='required'>
at line 21, then the schema is defining rules for an address element that has two attributes and no content: a mandatory type attribute whose only permitted value is bcc, and an optional uri attribute whose value is any string. It's a rather odd way to define an element with no content: it's actually defining it as an element that does have content, where the content must be an empty string. Perhaps the schema designers had a reason for this, but it's not immediately obvious.
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.
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.