dita — archive

[Kristen Eberlein]

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. 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> 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> 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