Use case for key scopes within subjectScheme maps

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

OK, I just ran into a use case for using key scopes in a subjectScheme map to define controlled values. The DITA 1.3 spec subjectScheme map, to be precise.

I added a <subjectdef> for values used on @otherprops, and used a <enumerationdef>to control the permitted values for @otherprops.

oXygen immediately told me that NO values were permitted for @otherprops. After scratching my head -- Why did oXygen think that I had an <enumerationdef> element with an empty <attributedef>? -- I went looking for key duplication, and it turned out that I had a collision between two keys named "example", one for @outputclass and now another for @otherprops.

I could see that the following (slimmed down) map would be useful, if one used the attribute value of "example" for both @outputclass and @otherprops. (For the point of view of simplifying the authoring experience, I like to keep attribute values as simple and consistent as possible.)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE subjectScheme PUBLIC "-//OASIS//DTD DITA Subject Scheme Map//EN" "subjectScheme.dtd">
<subjectScheme>

<subjectdef keys="outputclass-values">
        <subjectdef keys="cover"/>
        <subjectdef keys="example"/>
    </subjectdef>
   
    <subjectdef keys="otherprops-values" keyscope="otherprops">
        <subjectdef keys="example"/>
    </subjectdef>

 <enumerationdef>
        <attributedef name="outputclass"/>
        <subjectdef keyref="outputclass-values"/>
    </enumerationdef>
   
    <enumerationdef>
        <attributedef name="otherprops"/>
        <subjectdef keyref="otherprops.otherprops-values"/>
    </enumerationdef>

</subjectScheme>

--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)