Union and Lists

galexy — Wed, 10 Aug 2005 21:00:00 GMT

Last time we talked about built-in simple types and how additional types can be defined as restrictions of those types. Now, we will talk about the remaining kinds of simple types: unions and lists.

According to the W3C spec, list types are data types where the legal values are finite-length sequence of values. Each list type can be a list of a specific itemType. Within SQL Server 2005, we do not permit the creation of list of lists, list of union types and list of xs:ID. List types can be derived from the built-in atomic types, user defined restricted atomic types or anonymous types. The lexical representation of instances of list types are space delimited sequences of instances of the itemType. That means itemTypes that require spaces will not validate correctly when used within a list. For example, if I had a simple type that was a enumeration of three possible values "foo bar", "foo baz" and "bar baz", I would not be able to define a list of this type. When the validator runs across the instance "foo bar foo baz bar baz", it will try to validate "foo", "bar", "foo", "baz", "bar" and "baz" as instances of the itemType; all of which will fail. List types are XSD's intrinsic collection type. Although other mechanisms in XSD can be used to form collections of items, the list type may be more suitable for your needs. In additional to being able to create list types from atomic types, new types can derived from list types that restrict the list further by length, enumeration and pattern facets.

Union types are defined as types where the value and lexical space is the union of the value and lexical spaces of one or more simple types. You could create a union type that was the union of xs:duration and xs:time. During validation of an instance of this type, the lexical value will be validated against xs:duration first and if it doesn't pass validation, it will be validated against xs:time. However, if you want to have an instance validate against a specific memberType, you can specify that within the instance element via the xsi:type attribute. XSD unions are similar to C unions but have subtle differences. For one thing, the actual type of the value is not defined by a type descriptor. During validation, the PSVI is annotated with the actual type of the value.

CREATE XML SCHEMA COLLECTION foo AS N'
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tn="urn:test" targetNamespace="urn:test">
<xs:simpleType name="myAtomicType">
  <xs:restriction base="xs:string">
   <xs:pattern value="(ab)*"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="myList">
<xs:list itemType="tn:myAtomicType"/>
</xs:simpleType>

<xs:simpleType name="myAnonymousList">
  <xs:list>
   <xs:simpleType>
    <xs:restriction base="xs:int">
     <xs:totalDigits value="8"/>
    </xs:restriction>
   </xs:simpleType>
  </xs:list>
</xs:simpleType>

<xs:simpleType name="myUnion">
<xs:union memberTypes="tn:myAnonymousList tn:myAtomicType xs:float"/>
</xs:simpleType>
</xs:schema>'

I've created two list types, one that uses a type I've created, another using an anonymous type defined only within its scope. I've also created a union type that is a union of a list type, a restricted type and a builtin type.

Simple Types

galexy — Fri, 17 Jun 2005 01:05:00 GMT

My fellow team members have all blogged on static typing and anyone reading these blogs would be correct to conjecture that it is pretty important. There is so much to say about it and I'd rather not duplicate what my team members have written. For an introduction, read Denis' entry here and Mike's entry here. After reading these posts, it should be apparent that the point of static typing is to aid the developer in writing correct queries. Static typing is often used in other languages such as C# which are strongly typed. XQuery is a strongly typed language and implementations have the option of providing static type checking at query compile time. The XQuery implementation in SQL Server 2005 does in fact perform static type checking.

Before going into static typing, it is important to understand types within XML: where they come from, how they are defined and what can they "look" like. I will spend the next few posts talking just about types.

The type system in XQuery is based on XML Schema (XSD). If you don't plan on using XSD validation in your XML, you might think there is no point in learning more about types. However, static typing is still in affect when quering untyped XML within XQuery. The difference between typed and untyped instances is that the former is validated against an XSD collection. I won't go into the details of XSD, but I suggest those who are not familiar with it read Part 0 of the XSD specification.

Part 2 of the XSD specification talks about primitive and builtin types. XQuery inherits these builtin types into its own type system. Along with simple and complex types from XSD, XQuery defines node types. XQuery also has the notion of a sequence of items. Items are either atomic values or nodes. (Don't worry, these will become clear later)

Atomic types within XQuery are the builtin primitive types (simple types) and the types derived from these primitives by restriction ~~or union~~. XQuery defines a few extra simple types: xdt:untypedAtomic, xdt:anyAtomicType, xdt:yearMonthDuration and xdt:dayTimeDuration (SQL Server 2005 does not support the last two types). We will discuss these types in the future. Like XSD, the builtin types just exist and the user has the ability to introduce new types. In SQL Server 2005 we do this by creating an XSD schema collection. To create new atomic simple types, we have to restrict an existing atomic simple type. For example, if I wanted to create a type named foo that is an integer greater than 10, I would execute this DDL:

CREATE XML SCHEMA COLLECTION new_type_collection AS N'
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tn="urn:new_type" targetNamespace="urn:new_type">
    <xs:simpleType name="foo">
        <xs:restriction base="xs:integer">
            <xs:minExclusive value="10"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:element name="fooElement" type="tn:foo"/>
</xs:schema>'

I've also defined an element name fooElement. Assuming I have an XML instance, I can now use this type within a query.

declare @x xml(new_type_collection)
set @x = '<tn:fooElement xmlns:tn="urn:new_type">11</tn:fooElement>'
select @x.query('declare namespace tn="urn:new_type"; tn:foo("12") > /tn:fooElement')

Notice that I created an instance of the type foo by using a constructor syntax. What I have done is created an instance with the numeric value of 12 and then compare it to the value stored within the instance I am querying. In this case, the result is true. I can also create instances of builtin types with the constructor syntax:

declare @x xml(new_type_collection)
set @x = '<tn:fooElement xmlns:tn="urn:new_type">11</tn:fooElement>'
select @x.query('declare namespace tn="urn:new_type"; xs:integer("0") > /tn:fooElement')

Here, I've created an instance of xs:integer with the value 0 and compared it to the stored instance.

Okay, so now you know what builtin types are, how to create new restricted types from them via an XML Schema and how to create instances of these simple types within a query. The builtin simple types consist of string, date/time, floating point, decimal, integer, binary and various other types. To learn more about them, their semantics, restrictions and valid value and lexical spaces, read Part 2 of the XSD Specification. If you prefer to read a book try Definitive XML Schema by Priscilla Walmsley. Here is a diagram of the builtin type hierarchy.

Next time, I will talk about union and list types and their properties within XQuery.

Galex's Semi-Structured Blog : Xml Schema

Union and Lists

Simple Types