In last blog, we scan on some difficult part of XSD, in this tutorial, we continue with a problem lists to assist search.
Problem Lists
The following is the problems I met when working on it, and most answers are come from SO.
Define Element With Optinal Body?
<xs:element name="query" minOccurs="0" />
Define Enum?
<xs:simpleType name="dialects" final="restriction">
<xs:restriction base="xs:string">
<xs:enumeration value="oracle" />
<xs:enumeration value="inceptor" />
</xs:restriction>
</xs:simpleType>
Define Attributes Like maxOccurs
We can notice that the value of macOccurs
can be a non-negative number or a string – unbounded
. How does it defined?
The following is its definition:
<xs:simpleType name="allNNI">
<xs:union memberTypes="xs:nonNegativeInteger">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unbounded"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
Here it use union
to combine the range of non-negative integer and a string enumeration, which is easy to mimic by ourselves.
Allow elements in any order any number of times?
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="a" type="A"/>
<xs:element name="b" type="B"/>
</xs:choice>
Notice that the occurs
limitation should be at choice
level, otherwise we just let any one of them to appear many times, which waste us some time.
unbounded
Not Recognized
You can not use unbounded
in xs:all
, so you have to choose sequence or choice depend on whether your want element in order.
Inheritance
Using inheritance in xsd is not so straightforward and we came across many problems.
What we should notice is that what we want to achieve here is to limit father’s attribute, content/element definition in father, or to extend it.
Minimize the Range of Type – restriction
Restrictions are used to define acceptable values for XML elements or attributes
The following is a normal usage of restriction
, in which we constrain the range of string:
<xs:complexType name="parentType">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="childType">
<xs:complexContent>
<xs:restriction base="parentType">
<xs:sequence>
<xs:element name="name" type="specialStr"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
Class and Object
In some special case of using it, we can do some thing like defining an object (new type) of a class (old type) like following:
<xs:complexType name="A">
<xs:attribute name="p" type="xs:float" default="0.5"/>
</xs:complexType>
<xs:complexType name="B">
<xs:complexContent>
<xs:restriction base="A">
<xs:attribute name="p" fixed="1"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
In this case, we actually remove an attribute from father type by change it use property. But we should notice that restriction can only remove attributes that were optional in the original type.
Add New Member to Type – extension
Unlike restriction
, extension always adds things and cannot remove things (elements and attributes). It is used to extend original type. The following example shows that:
<xs:complexType name="A">
<xs:choice>
<xs:element name="c" type="C"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="B">
<xs:complexContent>
<!-- error to using xs:restriction here-->
<xs:extension base="A">
<xs:choice>
<!-- adding a new element -->
<xs:element name="d" type="d"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Relation Between Super’s Elements and Sub’s Elements
We sometimes may wonder, if we add some new elements by extension
, what the relationship between newly added elements and father type’s elements?
I didn’t find related reference, but we can test by some examples:
<xs:complexType name="A">
<xs:choice>
<xs:element name="a" type="xs:int"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="B">
<xs:complexContent>
<xs:extension base="A">
<xs:choice >
<xs:element name="b" type="xs:string"/>
<xs:element name="c" type="xs:double"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
valid one:
<B>
<a>1</a>
<b>AS</b>
</B>
invalid one:
<B>
<b>AS</b>
<a>1</a>
</B>
This shows that they are in order, which almost proves that they are organized by sequence
like following:
<xs:sequence>
<xs:choice>
<xs:element name="a"/>
</xs:choice>
<xs:choice>
<xs:element name="b"/>
<xs:element name="c"/>
</xs:choice>
</xs:sequence>
Or in more abstract way:
<xs:sequence>
// father element definition
// child element definition
</xs:sequence>
Ref
Written with StackEdit.
评论
发表评论