schemeref

A <schemeref> element provides a reference to another scheme. Typically, the referenced scheme defines a base set of controlled values extended by the current scheme. The values in the referenced scheme are merged with the current scheme; the result is equivalent to specifying all of the values in a single map.

Contains

Note: These models represent only the default document types distributed by OASIS. Actual content models will differ with each new document type.

Doctype	Content model
subjectScheme	( (topicmeta) (optional) then (data or data-about) (any number) )

Contained by

Doctype	Content model
subjectScheme	subjectScheme

Inheritance

- map/topicref subjectScheme/schemeref

Example: Extending a category with more specific values

Figure 1. The map baseOS.ditamap

<subjectScheme>
  <subjectdef keys="os" navtitle="Operating system">
    <subjectdef keys="linux" navtitle="Linux">
      <subjectdef keys="redhat" navtitle="RedHat Linux"/>
      <subjectdef keys="suse"   navtitle="SuSE Linux"/>
    </subjectdef>
    <subjectdef keys="mswin" navtitle="Windows"/>
    <subjectdef keys="zos"   navtitle="z/OS"/>
  </subjectdef>
  <enumerationdef>
    <attributedef name="platform"/>
    <subjectdef keyref="os"/>
  </enumerationdef>
</subjectScheme>

Figure 2. Second map that references baseOS.ditamap

Because a scheme establishes relationships between subjects rather than a contextual navigation structure, new relationships can be added to existing subjects. In particular, the referencing scheme can extend an enumeration by adding new relationships to existing subjects that belong to the enumeration. For instance, a scheme could extend the baseOS.ditamap scheme shown above by adding Macintosh OS as a child of the existing os subject and adding special versions of Windows under the existing mswin subject:

<subjectScheme>
  <schemeref href="baseOS.ditamap"/>
  <subjectdef keyref="os">
    <subjectdef keys="macos" navtitle="Macintosh"/>
    <subjectdef keyref="mswin">
      <subjectdef keys="winxp"  navtitle="Windows XP"/>
      <subjectdef keys="winvis" navtitle="Windows Vista"/>
    </subjectdef>
  </subjectdef>
</subjectScheme>

The references to the subjects defined by the base scheme use the keyref attribute to avoid duplicate definitions of the keys.

Figure 3. Resulting scheme

The result of merging the extension scheme with the base scheme is exactly the same as the following single scheme.

<subjectScheme>
  <subjectdef keys="os" navtitle="Operating system">
    <subjectdef keys="linux" navtitle="Linux">
      <subjectdef keys="redhat" navtitle="RedHat Linux"/>
      <subjectdef keys="suse"   navtitle="SuSE Linux"/>
    </subjectdef>
    <subjectdef keys="macos" navtitle="Macintosh"/>
    <subjectdef keys="mswin" navtitle="Windows">
      <subjectdef keys="winxp" navtitle="Windows XP"/>
      <subjectdef keys="win98" navtitle="Windows Vista"/>
    </subjectdef>
    <subjectdef keys="zos"   navtitle="z/OS"/>
  </subjectdef>
  <enumerationdef>
    <attributedef name="platform"/>
    <subjectdef keyref="os"/>
  </enumerationdef>
</subjectScheme>

Because the extended baseOS scheme bound the os subject to the platform attribute, the extension scheme doesn't provide that binding. The controlled values added by the extension to the hierarchy for the os subject become part of the enumeration bound to the platform attribute.

Example: Extending a category upwards

A category can also be extended upward. For instance, an extension scheme could create a Software category that includes operating systems as well as applications.

<subjectScheme>
  <schemeref href="baseOS.ditamap"/>
  <subjectdef keys="sw" navtitle="Software">
    <subjectdef keyref="os"/>
    <subjectdef keys="app" navtitle="Applications">
      <subjectdef keys="apacheserv" navtitle="Apache Web Server"/>
      <subjectdef keys="mysql"      navtitle="MySQL Database"/>
    </subjectdef>
  </subjectdef>
</subjectScheme>

If the extended baseOS scheme defines the binding of the os subject with the platform attribute, the app subjects provided by the extension scheme aren't subordinate to the os subject and thus don't become part of that enumeration. To leave open the possibility of upward extension of an enumeration, the content provider should define the controlled values in one scheme and define the binding to the attribute separately in a extension scheme. That way, the content provider can substitute a binding to a different extension without rework.

An adopter would identify the extension scheme as the scheme governing controlled values in the DITA environment. Any base schemes referenced by the extension scheme are, from a logical view, part of the extension scheme.

Attributes