Hi, Robert. See my comments below. Best, Kris Kristen James Eberlein Principal consultant, Eberlein Consulting Co-chair, OASIS DITA Technical Committee Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 3/7/2013 4:32 PM, Robert D Anderson wrote: My take ... For question #1 - I think the duplicate key is ignored, and that your understanding is correct. Where is that example today in the spec? I simplified the example severely to highlight the issue; as written, it does not exist in the spec. However, several topics show code examples of pulling in a base scheme using <schemeref> (but do not show an actual code sample of it or mention the key name) and then, as explained in a comment in the code sample, define new OS values that are merged with those in the [base] scheme. It's easy to read this and be unclear as to whether (1) a subject defined in the base scheme is being extended or (2) an additional subject is being defined. I think if it is (1), the existing subject needs to be referenced using the @keyref attribute, and if it is (2) then the new subject needs to be defined using the @keys attribute. I think this is an area where improving the code samples and explanations would clarify the issue. For question #2 - I think the goal there is to extend the values, rather than to override. The idea of a baseScheme pulled in with <schemeref> is that the baseScheme supplies a core set of value, and the local scheme extends it with local values (rather than changing it). I haven't done a deep read of this scenario in the spec lately, but it seems to be backed up by the definition of <schemeref>: Typically, the referenced scheme defines a base set of controlled values extended by the current scheme. The values in the referenced scheme are merged with the current scheme; the result is equivalent to specifying all of the values in a single map.
http://docs.oasis-open.org/dita/v1.2/os/spec/langref/schemeref.html That said, the examples in the spec show extending a category already associated with @platform, rather than defining a second set of values associated with @platform, so I don't think your exact example is covered today (at least in the examples I found in a quick check). My question rose out of trying to understand the following text in the <schemeref> topic, in the Example: Extending a category upwards section: If the extended baseOS scheme defines the binding of the os subject with the platform attribute, the app subjects provided by the extension scheme aren't subordinate to the os subject and thus don't become part of that enumeration. To leave open the possibility of upward extension of an enumeration, the content provider should define the controlled values in one scheme and define the binding to the attribute separately in a extension scheme. That way, the content provider can substitute a binding to a different extension without rework. An adopter would identify the extension scheme as the scheme governing controlled values in the DITA environment. Any base schemes referenced by the extension scheme are, from a logical view, part of the extension scheme. I've highlighted the text that led to my question about rebinding an attribute to a different subject. Kris Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (
http://dita-ot.sourceforge.net/ ) From: Kristen James Eberlein <
kris@eberleinconsulting.com> To: DITA TC <
dita@lists.oasis-open.org> , Cc: Eliot Kimber <
ekimber@reallysi.com> , Robert D Anderson/Rochester/IBM@IBMUS Date: 03/07/2013 14:34 Subject: Key precedence, binding of controlled values, and subjectScheme As I work through the subjectScheme topics, I've developed the following questions: 1) In the following scenario, what happens to the subject definition with a duplicate key? Is it ignored and thus the subject definitions that it contains are also ignored? <subjectScheme> <subjectdef keys= os > <subjectdef keys= solaris /> <subjectdef keys= hpunix /> </subjectdef> . . . <subjectdef keys= os > <subjectdef keys= linux /> <subjectdef keys= mswin /> <subjectdef keys= zos /> </subjectdef> We essentially have this code example in the spec. I would have assumed that the 2nd subject definition would need to reference the os subject by the @keyref attribute in order to merge additional subjects ... 2) What about the following situation? Is the 2nd binding of the @platform attribute ignored, or does it override the binding in the base scheme? Here is the contents of baseScheme.ditamap, which defines the os subject and binds its values to the @platform attribute: <subjectScheme> <subjectdef keys= os navtitle= Operating system > <subjectdef keys= linux navtitle= Linux > <subjectdef keys= redhat navtitle= RedHat Linux /> <subjectdef keys= suse navtitle= SuSE Linux /> </subjectdef> <subjectdef keys= mswin navtitle= Windows /> <subjectdef keys= zos navtitle= z/OS /> </subjectdef> <enumerationdef> <attributedef name= platform /> <subjectdef keyref= os /> </enumerationdef> </subjectScheme> Another subjectScheme map contains the following content: <subjectScheme> <schemeref href= /> . . . <subjectdef keys= app navtitle= Applications > <subjectdef keys= apacheserv navtitle= Apache Web Server /> <subjectdef keys= mysql navtitle= MySQL Database /> </subjectdef> . . . <enumerationdef> <attributedef name= platform /> <subjectdef keyref= app /> </enumerationdef> </subjectScheme> Best, Kris Kristen James Eberlein Principal consultant, Eberlein Consulting Co-chair, OASIS DITA Technical Committee Charter member, OASIS DITA Adoption Committee
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