DITA 2.0 and the <schemeref> element: Removing the concept of extending a subjectScheme

[Kristen James Eberlein <kris@eberleinconsulting.com>]

The <schemeref> element is part of the subjectScheme structural specialization (introduced in DITA 1.2). It can only be used within subject scheme maps. Its purpose is to reference a subject scheme map.

The processing expectations for the <schemeref> element were ill-defined for DITA 1.2 and 1.3.

[Main point] I want to propose that we change that for DITA 2.0. And rather than suggesting that we spell out the processing expectations for the current design, I want to suggest that we simply remove the idea of "extending a subject scheme"/using @keyref in a subjectScheme map to redefine subjects. If we do that, we end up with NO special processing for the <schemeref> element.

If you want more information, read on. Othwise, stop right here.

Here's how we suggested that "extending a subjectScheme" worked in the DITA 1.2 and 1.3 spec. I write "suggested",because this was only outlined in (non-normative) examples.

1. A company has a standard map (foo.ditamap) that creates an enumeration for @deliveryTarget.
   Example:
   
   <subjectScheme>
   ÂÂÂ <subjectdef keys="values-deliveryTarget">
   ÂÂÂÂÂ <subjectdef keys="html"/>
   ÂÂÂÂÂ <subjectdef keys="pdf"/>
   ÂÂÂÂÂ <subjectdef keys="serviceDatabase"/>
   ÂÂÂ </subjectdef> Â
   ÂÂÂ <enumerationdef>
   ÂÂÂ <attributedef name="deliveryTarget"/>
   ÂÂÂ <subjectdef keyref="values-deliveryTarget"/>
   Â </enumerationdef>
   </subjectScheme>
   
   
2. A division builds their department-specific map (foo-revised.ditamap). They want to add "ePub" as a value for @deliveryTarget, so they construct the following subjectScheme map, which uses the <schemeref> element to reference the company's standard subjectScheme map.
   
   <subjectScheme>
   Â <schemeref href=""/>
   ÂÂÂ <subjectdef keyref="values-deliveryTarget">
   ÂÂÂ <subjectdef keys="ePub"/>
   Â </subjectdef> Â
   </subjectScheme>
   
   
3. Processors were supposed to then build an effective subjectScheme map that looked like the following:
   
   <subjectScheme>
   ÂÂÂ <subjectdef keys="values-deliveryTarget">
   ÂÂÂÂÂ <subjectdef keys="html"/>
   ÂÂÂÂÂ <subjectdef keys="pdf"/>
   ÂÂÂÂÂ <subjectdef keys="serviceDatabase"/>
   ÂÂÂÂÂ <subjectdef keys="ePub"/>
   ÂÂÂ </subjectdef> Â
   ÂÂÂ <enumerationdef>
   ÂÂÂ <attributedef name="deliveryTarget"/>
   ÂÂÂ <subjectdef keyref="values-deliveryTarget"/>
   Â </enumerationdef>
   </subjectScheme>
   
   Note that this is the contents of foo.ditamap, with a single <subjectref> added (highlighted in bold).

Seems slick and useful, right? Yeah, but implementing this would require redesigning how a processor handled key resolution. To the best of my knowledge no processor has implemented any support for this behavior.

Here's what we'd do for DITA 2.0
We keep the <schemeref> element, but our processing expectations are simply standard key processing. For example, using the scenario outlined above, the division could use their department-specific subjectScheme to create an enumeration for @outputclass:

<subjectScheme>
 <schemeref href=""/>
 <subjectdef keys="values-outputclass">
ÂÂÂ <subjectdef keys="pull-quote"/>
ÂÂÂ <subjectdef keys="side-bar"/>
 </subjectdef>
 <enumerationdef>
ÂÂÂ <attributedef name="outputclass"/>
ÂÂÂ <subjectdef keyref="values-outputclass"/>
 </enumerationdef>
</subjectScheme>

--
Best,
Kris