Click here to Skip to main content
Click here to Skip to main content

XSD Tutorial - Part 5 of 5 - Other Useful Bits

, 3 Jul 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
This article gives a basic overview of the building blocks underlying XML Schemas.

XSD Tutorial Parts

  1. Elements and Attributes
  2. Conventions and Recommendations
  3. Extending Existing Types
  4. Namespaces
  5. Other Useful bits...

Introduction

This section covers a few of the lesser used constructs:

Element and Attribute Groups

Elements and Attributes can be grouped together using <xs:group> and <xs:attributeGroup>. These groups can then be referred to elsewhere within the schema. Groups must have a unique name and be defined as children of the <xs:schema> element. When a group is referred to, it is as if its contents have been copied into the location it is referenced from.

Note: <xs:group> and <xs:attributeGroup> cannot be extended or restricted in the way <xs:complexType> or <xs:simpleType> can. They are purely to group a number of items of data that are always used together. For this reason, they are not the first choice of constructs for building reusable maintainable schemas, but they can have their uses.

  <xs:group name="CustomerDataGroup">
    <xs:sequence>
      <xs:element name="Forename" type="xs:string" />
      <xs:element name="Surname" type="xs:string" />
      <xs:element name="Dob" type="xs:date" />
    </xs:sequence>
  </xs:group>

  <xs:attributeGroup name="DobPropertiesGroup">
    <xs:attribute name="Day" type="xs:string" />
    <xs:attribute name="Month" type="xs:string" />
    <xs:attribute name="Year" type="xs:integer" />
  </xs:attributeGroup>

The previous XSD shown graphically using Liquid XML Studio

These groups can then be referenced in the definition of complex types, as shown below.

<xs:complexType name="Customer">
    <xs:sequence>
        <xs:group ref="CustomerDataGroup"/>
        <xs:element name="..." type="..."/>
    </xs:sequence>
    <xs:attributeGroup ref="DobPropertiesGroup"/>
</xs:complexType>

The previous XSD shown graphically using Liquid XML Studio

The <any> Element

The <xs:any> construct allows us specify that our XML document can contain elements that are not defined in this schema. A typical use for this is when you define a message envelope. For example, the message payload is unknown to the system, but we can still validate the message.

Look at the following schema:

  <xs:element name="Message">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="DateSent" type="xs:date" />
        <xs:element name="Sender" type="xs:string" />
        <xs:element name="Content">
          <xs:complexType>
            <xs:sequence>
              <xs:any />
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

We have defined an element called "Message", which must have a "DateSent" child element (which is a date), a "Sender" child element (which must be a string), and a "Content" child element - which can contain any element - it doesn't even have to be described in the schema.

So the following XML would be acceptable.

<Message>
    <DateSent>2000-01-12</DateSent>
    <Sender>Admin</Sender>
    <Content>
        <AccountCreationRequest>
            <AccountName>Fred</AccountName>
        </AccountCreationRequest>
    </Content>
</Message>

The <xs:any> construct has a number of properties that can further restrict what can be used in its place.

minOccurs and maxOccurs allows you to specify how may instances of undefined elements must be placed within the XML document.

Namespace allows you to specify that the undefined element "must" belong to the given namespace. This may be a list of namespace's (space separated). There are also 3 built in values ##any, ##other, ##targetnamespace, ##local. Consult the XSD standard for more information on this.

processContents tells the XML parser how to deal with the unknown elements. The values are:

  • Skip - no validation is performed - but it must be well formed XML.
  • Lax - if there is a schema to validate the element, then it must be valid against it, if there is no schema, then that's OK.
  • Strict - There must be a definition for the element available to the parser, and it must be valid against it.

<anyAttribute>

<xs:anyAttribute> works in exactly the same way as <xs:any>, except it allows unknown attributes to be inserted into a given element.

  <xs:element name="Sender">
     <xs:complexType>
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:anyAttribute />
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
  </xs:element>

The previous XSD shown graphically using Liquid XML Studio

This would mean that we can add any attributes we like to the Sender element, and the XML document would still be valid.

<Sender ID="7687">Fred</Sender>

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Simon Sprott
Software Developer (Senior) Liquid Technologies
United Kingdom United Kingdom
No Biography provided

Comments and Discussions

 
GeneralAbout <xsd:annotation xmlns:xsd="#unknown"> ??</xsd:annotation> PinmemberSoftAshu26-Feb-09 18:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.141022.1 | Last Updated 3 Jul 2014
Article Copyright 2007 by Simon Sprott
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid