Re: [dita] Re: Key precedence, binding of controlled values, and subjectScheme

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

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