← Prev in month
← Prev in thread
Use case for key scopes within subjectScheme maps
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)
← Prev in month
← Prev in thread