I think so, maybe, with caveats. {Considers going on another rant about the folly of using keys for subject schemes; decides against.}
I think you'd want to put a scope around both subjectdefs; in the markup you have here, the definition of 'example' in 'outputclass-values' would override the scoped definition in 'otherprops-values'. From a pure key standpoint, since both 'example' entries
represent distinct values - and distinct keys - they should each be in their own scope. Does that matter for purposes of enumerations? No idea.
That said, your original problem stemmed from the fact that we use keys for subject definitions, which impose the limitation of having only one definition per value across all subjects, which is yet another argument against using keys for that purpose.
You're using key scopes to work around a limitation of keys in a context where we shouldn't have used keys in the first place.
(Looks like I went ahead and ranted a bit anyway. Couldn't be helped.)
All that said, I would expect this to be among the very last features to be implemented by vendors, so while it makes theoretical sense to use scopes to differentiate the values, it may not work practically for quite some time.
Chris
|
Chris Nitchie (734) 330-2978 |
|
|||
|
Follow us: |
|
|
|
|
From: Kristen James Eberlein
Date: Monday, April 27, 2015 at 7:53 PM
To: DITA TC
Subject: [dita] Use case for key scopes within subjectScheme maps
Date: Monday, April 27, 2015 at 7:53 PM
To: DITA TC
Subject: [dita] 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)
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php