I have this xsd
<xs:attributeGroup name="PropertyAttributes">
<xs:attribute name="IsAttached" type="xs:boolean" default="false" />
<xs:attribute name="IsStatic" type="xs:boolean" default="false" />
</xs:attributeGroup>
I like to restrict this case
IsAttached=true IsStatic=true
How can I do this?
You cannot achieve this in XSD 1.0; you have to either move to XSD 1.1 (the only freely available processor that I know of is Xerces, and that is in beta status) OR augment your XSD 1.0 model with Schematron (the latter being XSLT 1.0/2.0 based, you have options galore).
Related
Here is a small schema, and a sample XML file, that will validate successfully at the Xerces-J online validation service if XSD version 1.1 is selected, but not XSD 1.0.
With 1.0 selected, the schema itself is rejected, as invalidly deriving t2 from t1. (The intent is that t1 allows an optional thing and some stuff, and t2 is a restriction that keeps the stuff but forbids the thing.)
The exact complaint from Xerces-J with 1.0 selected is:
[Error] foo.xsd:19:28:rcase-Recurse.1: Group's occurrence range, (0,unbounded), is not a valid restriction of base group's occurrence range, (1,1).
[Error] foo.xsd:19:28:derivation-ok-restriction.5.4.2: Error for type 't2'. The particle of the type is not a valid restriction of the particle of the base.
I think what happens is the containing <sequence> in t2 gets considered "pointless" (2.2.2.2.1 here) because it now has only one child, but the corresponding <sequence> in t1 is not "pointless" because it has two children, and the derivation checker is trying to match the minOccurs and maxOccurs of t2's <group> against those of t1's <sequence>. Somehow, the checker for XSD 1.1 manages to be smarter than that.
So my question (ok, two questions):
Is this behavior in 1.0 an inherent known limit of XSD 1.0 that the derivation rules in 1.1 were updated to fix, or is it a limit of the Xerces-J implementation of 1.0? Does anybody have a 1.0 implementation that accepts this schema?
Given the continued deployment of tools that use 1.0, does anyone know an alternate way to write this schema that will work in 1.0? (I can make this example work by losing the <group> and inlining the <stuff> element both places, but that's not a plan if the real-life group has more than one child).
Edit: even the inlining workaround is unavailing if the element heads a substitution group. That gets reified here as a <choice> group, which again has its minOccurs and maxOccurs mismatch those of the base type's <sequence>.
foo.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="foo:bar"
xmlns="foo:bar">
<xs:group name="stuffGroup">
<xs:sequence>
<xs:element name="stuff"/>
</xs:sequence>
</xs:group>
<xs:complexType name="t1">
<xs:sequence>
<xs:element name="thing" minOccurs="0"/>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="t2">
<xs:complexContent>
<xs:restriction base="t1">
<xs:sequence>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="a" type="t2"/>
</xs:schema>
foo.xml:
<a xmlns='foo:bar'/>
The Microsoft .NET XSD 1.0 based schema validator rejects your schema with an error in line 19 saying (citing first the German message I get from VS): "
Warnung Ungültige Partikelableitung durch Einschränkung - 'Gemäß All:All,Sequence:Sequence -- Recurse-Regel 1 oder Choice:Choice -- RecurseLax ist der Bereich des abgeleiteten Partikels keine gültige Einschränkung des Basispartikelbereichs.'." which I would translate roughly as "Warning invalid particle inference by restriction - according to All:All,Sequence:Sequence -- Recurse-rule 1 oder Choice:Choice -- RecurseLax is the domain of the inferred particle no valid restriction of the base particle domain".
Xmllint ("xmllint: using libxml version 20910"), on the other hand, when trying to validate the sample against the schema with e.g. command line options --schema schema1.xsd sample1.xml reports:
<?xml version="1.0"?>
<a xmlns="foo:bar"/>
sample1.xml validates
I will need to dig deeper in the schema specs the judge what is the right behaviour.
Given a schema that defines an element of a certain type, is it possible to allow that type to be extended, but still have that extension element be strongly typed? In other words, add some kind of extension point that can be used from an external schema to add elements that can only be used in this location?
Let's say the schema looks kinda like:
<xs:schema …>
<xs:element name="Match" type="tns:TNodeConstraint" />
<xs:complexType name="TNodeConstraint">
<xs:group ref="tns:Expression" />
</xs:complexType>
<xs:group name="Expression">
<xs:choice>
<xs:element name="And">
<xs:complexType … />
</xs:element>
<xs:element name="Or">
<xs:complexType … />
</xs:element>
<xs:element name="IsAbstract">
<xs:element name="IsExtern">
<!-- Some kind of extension point? -->
</xs:choice>
</xs:group>
</xs>
Is it possible to extend the Expression group so that a second, external schema could say that I can accept IsMyCustomConstraint here, but not IsMyCustomSortOrder? So this will be valid:
<Match>
<IsAbstract />
<IsExtern />
<IsMyCustomConstraint />
</Match>
But this would be invalid?
<Match>
<IsAbstract />
<IsExtern />
<IsMyCustomSortOrder />
</Match>
I don't want to use xs:any as that would allow putting a "sort order" where a constraint can go.
I can modify the original schema
I'm in control of what the namespaces of IsMyCustomConstraint and IsMyCustomSortOrder would be, and it's not important if they match the original schema or not.
is it possible to allow that type to be extended, but still have that extension element be strongly typed?
Definitely - this is described in detail, with examples, here: https://www.w3.org/TR/2000/WD-xmlschema-0-20000225/#DerivExt. As far as I can tell, you just need to declare one or more complex types that are extensions of your base type 'TNodeConstraint'.
XML schema has a rich set of facilities to support type inheritance including:
abstract base types (base type must be extended or restricted before use)
extension (new type allows more values than the base type)
restriction (new type allows fewer values than the base type)
control of whether further extensions/restrictions are allowed (final/block attributes)
I don't see any need to use a separate XSD for the extensions, although you can if you want to. You may find it useful to know about xsi:type, abstract types and the block/final attributes - all are described the XML Schema Part 0 - Primer mentioned above.
I am trying to apply pattern for an element in xsd.
Element is of type XHTML.
I want to apply pattern like this.
<a attributes="some set of attributes"><img attributes="some set of attribtes"/></a>
Rules:
<a> tag with attributes followed by <img> with attributes.
Sample Valid Data:
<a xlink:href="some link" title="Image" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/1999/xhtml">
<img alt="No Image" title="No Image" xlink:href="soem path for image" xlink:title="Image" xmlns="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink" />
</a>
Invalid:
<a>data<img/></a>--Data Present, no attributes
<a><img>abcd</img></a>--data Present, No attributes
<a><img/></a>---No attributes
Can any one suggest how to write pattern for this.
<xsd:restriction base="xs:string">
<xs:pattern value="Need help"/>
</xsd:restriction>
Thank you.
The XSD pattern facet is used to constrain the 'lexical space' of a simple type (that is, the set of literal strings that denote instances of the type) using regular expressions. It won't help you to require that certain elements must have attributes.
If you want specific attributes to be present (e.g. title and xlink:href on the a element, title and alt on the img element), the simplest way to do so in a schema is by declaring those attributes as required. The schema for XHTML 1.0 strict, for example (at http://www.w3.org/TR/xhtml1-schema/#xhtml1-strict) declares both src and alt as being required on img:
<xs:element name="img">
<xs:complexType>
<xs:attributeGroup ref="attrs"/>
<xs:attribute name="src" use="required" type="URI"/>
<xs:attribute name="alt" use="required" type="Text"/>
...
</xs:complexType>
</xs:element>
If what you want is just to require that some attributes be used, but you don't care which, XSD doesn't make the task easy: in XSD 1.0 there is no convenient way to say "I don't care which attribute appears, but there has to be one". You can enforce such a constraint (even if some observers like me find it a bit odd) by using assertions in XSD 1.1, or by using a Schematron schema in addition to your XSD schema.
I need to specify a XSD for validating XML documents. The XSD will be used for a JAXB generation of Java bindings.
My problem is specifying optional elements which I do not know the names of and which I in general am not interested in parsing.
The structure of the XML documents is like:
<TRADE>
<TIME>12:12</TIME>
<MJELLO>12345</MJELLO>
<OPTIONAL>12:12</OPTIONAL>
<DATE>25-10-2011</DATE>
<HELLO>hello should be ignored</HELLO>
</TRADE>
The important thing is, that:
I can not assume any order, and the next XML document instance migtht have tags in a different order
I am only interested in parsing some of the tags, some are mandatory and some are optional
The XML documents can be extended with new elements which I am not interested in parsing
The structure of my XSD is like (not a valid xsd):
<?xml version="1.0" encoding="ISO-8859-1"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- *********************************************** -->
<!-- Trade element definitions for the XML Documents -->
<!-- *********************************************** -->
<xs:complexType name="Trade">
<!-- Using the all construction ensures that the order does not matter -->
<xs:all>
<xs:element name="DATE" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="TIME" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="OPTIONAL" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:any minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- TRADE is the mandatory top-level tag -->
<xs:element name="TRADE" type="Trade"/>
</xs:schema>
So, in this example: DATE and TIME are mandatory (they must be in the XML exactly once), OPTIONAL might be present once and then I would like to specify, that all other tags are allowed. The order does not matter.
How do I specify a valid XSD for this?
This is a classic parser problem.
Basically, your BNF is:
Trade = whatever whatever*
whatever = "DATE" | "TIME" | anything
anything = a-z a-z*
But this is ambigous. The string "DATE" can both be accepted under the whatever rule as "DATE" and as anything.
So if you have
<TRADE>
<TIME>12:12</TIME>
<DATE>25-10-2011</DATE>
<DATE>25-12-2011</DATE>
</TRADE>
it is unclear whether that should be accepted or not.
It could be interpreted either one of
"TIME", "DATE", anything
anything, anything, "DATE"
anything, anything, anything
"TIME", "DATE", anything
"TIME", "DATE", "DATE"
etc.
It all boils down to: If you have a wildcard combined with random sequence, you cannot meaningfully decide which token matches which rule.
It especially does not make sense to have optional elements together with a wilcard.
You have two options:
use xs:sequence instead of xs:all
do not use wildcard
As I understand it, both options are in conflict with your wishes.
Perhaps you can construct a wildcard that matches everything except DATE, TIME etc.
Is it a hard requirement to have JAXB bindings to your "known" elements?
If not, you can basically have just <any maxoccurs="unbounded" processContents="skip"/> as your xsd, and then pick out the elements you are interested in from the DOM tree.
(See here how to use JAXB without data binding.)
I'm new to XSD, and I'm quite confused as to when to use attribute, and when to use element?
Why cant we specify minOccurs and maxOccurs in attribute?
Also, why is it we cannot specify use="required" in element?
An element is an XML element - a opening tag, some content, a closing tag - they are the building blocks of your XML document:
<test>someValue</test>
Here, "test" would be an element.
Attributes is an additional info on a tag - it's an "add-on" or an extra info on an element, but can never exist alone:
<test id="5">somevalue</test>
"id" is an attribute.
You cannot have multiple attributes of the same name on a single tag --> minOccurs/maxOccurs makes no sense. You can define required (or not) for an attribute - anything else doesn't make sense.
The elements are defined by their occurrence inside complex types - e.g. if you have a complex type with a <xs:sequence> inside - you are defining that all elements must be present and must the in this particular order:
<xs:complexType name="SomeType">
<xs:sequence>
<xs:element name="Element1" type="xs:string" />
<xs:element name="Element2" type="xs:string" />
</xs:sequence>
</xs:complexType>
Inside an element of that type, the sub-elements "Element1" and "Element2" are required and must appear in this order - there's no need for "required" or not (like with attributes). Whether or not an element is required is defined by the use of minOccurs and maxOccurs; both are =1 by default, e.g. the element must occur, and can only occur once. By tweaking those settings, you can define an element to be optional (minOccurs=0), or allow it to show up several times (maxOccurs > 1).
I'd strongly recommend you check out the W3Schools Tutorial on XML Schema and learn some more about XML schema.
Marc
Example: XSD Format
<xs:complexType name="contactInformation">
<xs:all>
<xs:element name="firstName" type="xs:string" minOccurs="0"/>
<xs:element name="workCountryId" type="xs:long" minOccurs="0"/>
</xs:all>
<xs:attribute name="id" type="xs:long"/>
</xs:complexType>
XML Format
<contactInformation id=100>
<firstname>VELU</firstname>
<workCountryId>120</workCountryId>
</contactInformation>
attribute is optional by default. To specify that the attribute is required, use the use attribute:
e.g. <xs:attribute name="id" type="xs:long" use="required"/>
More about attributes and elements.
A complexType element is an XML element that contains other elements and/or attributes.
The all element specifies that the child elements can appear in any order and that each child element can occur zero or one time.
maxOccurs Optional. Specifies the maximum number of times the element can occur. The value must be 1.
minOccurs Optional. Specifies the minimum number of times the element can occur. The value can be 0 or 1. Default value is 1
An element is an XML node - and it can contain other nodes, or attributes. It can be a simple type or a complex type. It is an XML entity.
An attribute is a descriptor. It can't contain anything and can only be a simple type.
Have a look at this. Of course, you can just google something like "XML element vs attribute"
<element myAttribute="value">
<subElement />
<subElement anotherAttribute="this is an attribute's value">Element value</subElement>
</element>
You can't have more than one attribute with the same name in XML, therefore you can't use minOccurs and maxOccurs for attributes.
You don't need use="required" for elements because you can have minOccurs="1" instead.
It is your choice when to use attributes and when to use elements. Here are some guidelines: http://www.ibm.com/developerworks/xml/library/x-eleatt.html