XML Schema: Coding requirements for element type declarations

Darwin Information Typing Architecture (DITA) Version 1.3 Part 1: Base Edition

Document
Darwin Information Typing Architecture (DITA) Version 1.3 Part 1: Base Edition
Version
1.3
Author
OASIS DITA Technical Committee

Structural and domain vocabulary modules have the same XSD coding requirements for element type declarations.

Element definitions

A structural or domain vocabulary module must contain a declaration for each specialized element type named by the module. While the XSD standard allows content models to refer to undeclared element types, all element types named in content models within a vocabulary module must have an xs:element declaration, either in the vocabulary module, in a base module from which the vocabulary module is specialized, or in a required domain module.

Domain modules consist of a single XSD document. Structural modules consist of two modules; one module contains all element name groups, and the other contains all other declarations for the module.

For each element type that is declared in the vocabulary module, the following set of groups and declarations must be used to define the content model and attributes for the element type. These groups are typically placed together within the module for clarity.

  • For each element type declared in the vocabulary module there must be an xs:group element whose name is the element type name, and whose one member is a reference to the element type. This element name group provides a layer of abstraction that facilitates redefinition. A document-type shell can redefine an element group to add domain-specialized elements or to replace a base element type with one or more specializations of that type.
  • Each element type must have a corresponding content model group named tagname.content. The value of the group is the complete content model definition; the content model group can be overridden in constraint modules to further constrain the content model.
  • Each element type must have a corresponding attribute group named tagname.attributes. The value of the group is the complete attribute set for the element type, except for the class attribute. Like the content model, this group can be overridden in a constraint module to constrain the attribute set.
  • Each element type must have a complex type definition named tagname.class, which references the tagname.content and tagname.attributes groups.
  • Each element type must have an xs:element declaration named tagname, that uses as its type the tagname.class complex type and extends that complex type to add the class attribute for the element.
For example, the following set of declarations shows each of the required groups and definitions for the specialized codeph element.
<xs:group name="codeph">
  <xs:sequence>
    <xs:choice>
      <xs:element ref="codeph"/>
    </xs:choice>
  </xs:sequence>
</xs:group>

<xs:group name="codeph.content">
  <xs:sequence>
    <xs:choice minOccurs="0" maxOccurs="unbounded">
      <xs:group ref="basic.ph.notm"/>
      <xs:group ref="data.elements.incl"/>
      <xs:group ref="draft-comment"/>
      <xs:group ref="foreign.unknown.incl"/>
      <xs:group ref="required-cleanup"/>
    </xs:choice>
  </xs:sequence>
</xs:group>

<xs:attributeGroup name="codeph.attributes">
  <xs:attributeGroup ref="univ-atts"/>
  <xs:attribute name="outputclass" type="xs:string"/>
  <xs:attributeGroup ref="global-atts"/>
</xs:attributeGroup>

<xs:complexType name="codeph.class" mixed="true">
  <xs:sequence>  
    <xs:group ref="codeph.content"/>
  </xs:sequence>        
  <xs:attributeGroup ref="codeph.attributes"/>
</xs:complexType>

<xs:element name="codeph">
  <xs:annotation>
    <xs:documentation> <!-- documentation for codeph --> </xs:documentation>
  </xs:annotation>
  <xs:complexType>
    <xs:complexContent>
      <xs:extension base="codeph.class">
        <xs:attribute ref="class" default="+ topic/ph pr-d/codeph "/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:element>