Abstract

XSDL allows greater flexibility in defining constraints on intra-document references than the ID/IDREF construct of DTDs. XSDL's Identity Constraints are scoped, typed, and can be used for elements or attributes. They are more powerful that the DTD's limited ID/IDREF mechanism, but still lack sufficient generality to support a really wide set of model constraints to be expressed.

Named and Anonymous Types

• Types can be named or anonymous
  • named types can be reused (for elements, attributes, or type derivation)
  • anonymous types can only be used where they are defined
• DTD types are always anonymous (they cannot be reused)

<!ELEMENT person (name, address) >
<!ATTLIST person id ID #REQUIRED >

• DTDs have everything hardcoded
  • complex types are always locally defined
  • elements are always globally defined
  • attributes are always locally defined

Local vs. Global Elements

• Elements can be defined in a type or in the schema
  • local elements can only be used where they are defined
  • global elements can be reused, they can serve as building blocks
• Elements and complex types depend on each other
  • an element is defined by a type, often this will be a complex type
  • a complex type is defined by its contents, which are elements and/or attributes

 <xs:complexType name="mixedType" mixed="true">
  <xs:choice maxOccurs="unbounded" minOccurs="0">
   <xs:element ref="b"/>
   <xs:element name="i" type="xs:string"/>
   <xs:element name="u" type="xs:string"/>
  </xs:choice>
  <xs:attribute ref="class"/>
 </xs:complexType>
 <xs:element name="b" type="xs:string"/>

Reusable Elements

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="billingAddress" type="addressType"/>
 <xs:element name="shippingAddress" type="addressType"/>
 <xs:complexType name="addressType">
  <xs:sequence>
   <xs:element name="name" type="xs:string"/>
   <xs:element name="street" type="xs:string"/>
   <xs:element name="city" type="xs:string"/>
   <xs:element name="state" type="xs:string" minOccurs="0"/>
   <xs:element name="zip" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="country" type="xs:NMTOKEN"/>
 </xs:complexType>
</xs:schema>

Attribute Definitions

• DTDs treat attributes as something entirely different from element content
  • they are defined in an ATTLIST, not in the ELEMENT definition

    <!ELEMENT person (name, address) >
    <!ATTLIST person id ID #REQUIRED >

  • they have a special range of Attribute Types as opposed to elements

    <!ATTLIST person id ID #REQUIRED >

• XSDL overcomes these restrictions only partially
  • Simple Types are used to define attribute (or element) contents
  • attributes are still described as something entirely different from an element's content model
• Attributes could be better integrated into the model
  • RELAX NG treats attributes as part of an element's content model
  • this makes it trivial to have choices of element content and attributes

Reusing Attributes

• DTDs treat attributes as something local to an element
  • attributes are defined in an element's ATTLIST
  • reusing attributes for more than on element requires Parameter Entities
• XSDL better supports reuse of schema components
  • types can be defined locally (anonymous) or globally (named)
  • elements and attributes can be defined globally or locally
• Globally defined attributes can be reused
  • the attribute definition does not tie it to any occurrence
  • the attribute can then be referenced from an complex type definition

Reusing Attributes (Example)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="p" type="mixedType"/>
 <xs:complexType name="mixedType" mixed="true">
  <xs:choice maxOccurs="unbounded" minOccurs="0">
   <xs:element ref="b"/>
   <xs:element name="i" type="xs:string"/>
   <xs:element name="u" type="xs:string"/>
  </xs:choice>
  <xs:attribute ref="class"/>
 </xs:complexType>
 <xs:element name="b" type="xs:string"/>
 <xs:attribute name="class">
  <xs:simpleType>
   <xs:restriction base="xs:string">
    <xs:enumeration value="comment"/>
    <xs:enumeration value="warning"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:attribute>
</xs:schema>

Definitions

• Many XSDLs define a vocabulary for a namespace
  • DTDs do not have any support for namespaces
  • XSDL heavily builds on XML Namespaces
• XSDL provides support for declaring a vocabulary's namespace

  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/">

• Schema-validation can check for proper namespace usage
  • the targetNamespace has to be used in the instance
  • if the namespace does not match, validation cannot succeed

Instances

• The schema defines the targetNamespace of the vocabulary
  • all globally defined elements, attributes, and types are in that namespace
  • the instances must declare and use the namespace to be schema-valid

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>Multicolumn Layout in HTML</title>
  <style type="text/css">

• A prefixed name is not the same as a qualified name
  • if there is a default namespace, unprefixed elements are still qualified
• Nasty details about XML Namespaces and attributes
  • the default namespace does not apply to attributes
  • attributes must therefore always be prefixed if they need to be qualified

Name Qualification

• Global elements and attributes have to be used as qualified names
  • this means that they must be referred to by their namespace-qualified name
  • if a default namespace is used, elements are qualified without carrying a prefix
  • since the default namespace does not apply to attributes, they always must be explicitly prefixed
• Local elements and attributes may be used qualified or unqualified
  • this control only applies to locally define elements or attributes
  • the default defined by XSDL is not a good choice
  • because of how XML Namespaces work, a non-default choice is recommended
• XSDL allows control over how local names have to be used

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/" elementFormDefault="qualified" attributeFormDefault="unqualified">

Element = Type + Constraints

• DTDs and XSDL are mainly about specifying grammars
  • types describe the allowed values using grammars
  • grammar-oriented schemas have some nice properties
• DTD's ID/IDREF allow additional constraints
  • apart from the grammar definition, cross-references in the tree are supported
  • validation checks the integrity of the cross-references, not only the tree
• DTD's ID/IDREF are a very simple mechanism
  • they are always global
  • they also define the type of the attribute (XML names)

Improvements over ID/IDREF

• XSDL's Identity Constraints improve DTD's ID/IDREF
• Identity constraints are scoped and apply only to a selected set of nodes
  • the constraint applies only to a selected set of nodes (using XPath)
• Identity constraints are evaluated using typed values
  • IDs must be XML names (no numbers allowed)
  • 2 ≟ +00002 should be evaluated based on the type (string or decimal?)
  • XSDL separates the constraint from the type of the selected nodes
• Identity constraints may select elements or attributes
  • XPaths are used to select the constrained values, they can select elements or attributes
• Multiple fields
  • it is possible to select more than one field for a constraint (phone & area code must be unique)

Types of Identity Constraints

• Uniqueness constraints
  • if there is a field, it must have a unique value among the selected nodes
• Key constraints
  • there must be a field, and it must have a unique value among the selected nodes
• Key reference constraints
  • the field must refer to an existing value in the referred key
  • if the key reference also is constrained by a key, only one reference may use the referred key

Identity Constraint Definitions

• Identity constraints are part of an element definition
• There are three important factors to an identity constraint
  1. location of the identity constraint's definition
  2. the nodes to which the constraint should be applied
  3. the fields which are used to evaluate the constraint
• If the constraint is a key reference constraint, there is a fourth factor
  4. the key constraint that is used for checking the references

Identity Constraint Evaluation

Advanced Identity Constraints

XSDL Features

• Identity constraints enable non-grammar constraints to be expressed
• XSDL identity constraints are more powerful than the DTD ID/IDREF concept
• Only a subset of structural constraints can be expressed in XSDL
• XSDL 1.1 introduces the concept of assertions (XPath-based constraints)