Efficiency shortcuts

Parameter entities are often used in DTDs to avoid unnecessary duplication, to clarify content models, and to generally make maintenance of the DTD easier. Although parameter entities cannot be used in XML Schema documents (or indeed any XML document), it is possible to use general entities instead. However, the XML Schema standard includes its own (arguably simpler) mechanisms to achieve the same aims, so avoiding the need for entities of any kind.

Shared content models

When a number of element content models are identical, it is not efficient to replicate the model in each element definition (and document model clarity and ease of future maintenance also suffers). Instead, the complex model can be created in isolation, using the ComplexType element, but this time given a name using the Name attribute. This name can be referenced from within each relevant element declaration, using the same Type attribute that is used to reference simple data types:

<complexType mixed="true" name="MixedInline">
  <choice minOccurs="0" maxOccurs="unbounded">
    <element ref="emph" />
    <element ref="name" />
  </choice>
</complexType>

<element name="title" type="DOC:MixedInline />

<element name="para" type="DOC:MixedInline />

<!-- DTD EQUIVALENT:
     <!ENTITY % MixedInline "(#PCDATA | emph | name)*" >
     <!ELEMENT para  (%MixedInline;)>
     <!ELEMENT title (%MixedInline;)> -->

Note

The Ref and Type attributes should not be confused. The Ref attribute is always used to refer to an object of the same kind as the element it is in. It is used, for example, by an element (reference) to refer to another element (definition), or by an attribute (reference) to refer to another attribute (definition). The Type attribute, however, is used to reference a simple data type, such as 'string', or a complex data type, such as the model above.


This technique achieves much more than simply providing the means to share content models. It creates a new, custom complex data type that can be referenced and exploited in a number of ways (mostly covered by features described in the next chapter).

Groups

When only part of the content model is common to a number of element definitions, a variant of the technique described above uses the Group element, instead of the ComplexType element. This element has both a Name attribute and a Ref attribute. When it is used to define a common group, it may contain either a Choice group or a Sequence group (or a third option that is described in the next chapter). When this element is used as a reference, the MinOccurs and MaxOccurs attributes may be used:

<group name="Reference">
  <choice>
    <element ref="WebSite" />
    <element ref="book" />
  </choice>
</group>

<element name="citation">
  <complexType>
    <sequence>
      ...
      <group ref="DOC:Reference" minOccurs="0"
                                 maxOccurs="unbounded"/>
      ...
    </sequence>
  </complexType>
</element>

<!-- DTD EQUIVALENT:
  <!ENTITY % Reference "(WebSite | book)" >
  <!ELEMENT citation  (... , (%Reference;)* , ...)> -->

Shared attribute declarations

Just as content models can be defined in isolation, then referenced from within element definitions, attributes can also be referenced in the same way (at the end of a ComplexType definition), using the Ref attribute. The Use attribute is used in references (just as the occurrence attributes are used in element references):

<attribute name="security" ... />

<element name="chapter">
  <complexType>
    ...
    <attribute ref="DOC:security" use="required"/>
  </complexType>
</element>

<element name="para">
  <complexType>
    ...
    <attribute ref="DOC:security" use="optional"/>
  </complexType>
</element>

Note that the Use attribute has no meaning in the isolated declaration, but can be used in each reference, and given a different value in each case.

Warning

This technique (when applied to attributes rather than to elements) is not as useful as it first appears, because it creates attributes that belong to a specific namespace, rather than directly to the element. This means that the attribute must always have a suitable namespace prefix when used in an element instance, even though the namespace this prefix maps to will be the same as the default or explicit namespace that the whole element maps to (the next technique, using attribute groups, is usually more appropriate):


<B:book xmlns:B         = "file:///d:/ns/myBookNamespace"
        xmlns:ATTRIBUTE = "file:///d:/ns/myBookNamespace">
  ...
  <B:chapter ATTRIBUTE:security="normal">...</B:chapter>
  ...
</B:book>

Attribute groups

When a number of element types require the same set of attributes, it is possible to pre-define and name a group of attributes, then refer to this group in each element definition. The AttributeGroup element has the usual Name and Ref attributes, and contains any number of attribute definitions and attribute references. When used as a reference, it appears at the end of a ComplexType declaration:

<attribute name="security" ... />

<attributeGroup name="standardAtts">
  <attribute name="id" type="ID" use="required"/>
  <attribute name="indentLevel" type="string" />
  <attribute ref="DOC:security" />
</attributeGroup>

<element name="chapter">
  <complexType>
    ...
    <attributeGroup ref="DOC:standardAtts" />
  </complexType>
</element>

<element name="para">
  <complexType>
    ...
    <attributeGroup ref="DOC:standardAtts" />
  </complexType>
</element>

<!-- DTD EQUIVALENT (apart from attribute name and
     Security attribute referencing issue):
  <!ENTITY % security     "security    CDATA #IMPLIED">
  <!ENTITY % standardAtts "id          ID    #REQUIRED
                           indentLevel CDATA #IMPLIED
                           %security;" >

  <!ATTLIST chapter  %standardAtts; >
  <!ATTLIST para     %standardAtts; > -->

An attribute group can also contain references to other attribute groups.

This technique should also be used for single attributes that need to be shared, as it overcomes the namespaces issue raised above concerning global single attribute definitions (a problem that still occurs with the Security attribute in the example above).

Also note that if all of the elements concerned will have identical content models, as well as identical attributes, it is possible to define a named complex type definition that includes both the model and the attributes needed. In addition, there is nothing to prevent this complex type definition from referencing attribute groups.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.104.29