Implication of subjectdef with a keyref (was Gathering restricted values using a subject scheme map)

[Eliot Kimber <ekimber@contrext.com>]

Radu's example has a top-level subjectdef that is then referenced by key from within another top-level subjectdef. This example can be generalized as:

<subjectdef keys="toplevel-01">
  <subjectdef keys="child-01"/>
</subjectdef>
<subjectdef keys="toplevel-02">
  <subjectdef keys="child-02"/>
  <subjectdef keyref="toplevel-01"/>
</subjectdef>
<enumerationdef>
  <attributedef name="attribute-A"/>
  <subjectdef keyref="toplevel-02"/>
</enumerationdef>

The question is what is the implication of the keyref to toplevel-01 within toplevel-02?

The specification says that top-level subjectdefs (by which I think we mean subjectdefs with no direct-parent subjectdefs) define categories and that their children/descendants (spec is inconsistent on this point) define the allowed values. (2.2.3.2 "Defining controlled values for attributes" and 2.2.3.4 "Processing controlled attribute values")

Because toplevel-01 is a top-level subject definition, it clearly defines a category.

However, the language in 2.2.3.4 "Processing controlled attribute values" makes it clear that all the descendants of a top-level subject definition are treated as potential values. In that case, non-leaf, non-root subject definitions act as both categories (in the sense that they name and collect a set of subordinate subjects) and values.

Given that, my analysis is that the reference to a root subject from within another subject must treat the referenced subject as though it had occurred at the point of reference, namely that it defines both an allowed value and a category containing it's descendant subjects (if any).

If this were not the case then in the example above it would be impossible to define an enumerated list where the allowed values were ["child-02", "toplevel-01"] because it would be impossible to declare the subject "toplevel-01" as both a top-level subject and a descendant subject because of key precedence rules (because only the first definition of toplevel-01 would be used).

However, if toplevel-01 is treated as a value when referenced, then it would be possible to define the value list for toplevel-02 as either ["child-02", "toplevel-01", "child-01"] (reference to "toplevel-01") or just ["child-02", "child-01"] (reference to "child-01" instead of to "toplevel-01".

That is, an interpretation of the spec that says top-level subjects are treated as top-level subjects in all use contexts disallows at least one important use case.

One counter argument to this analysis would be to require the use of key scopes: because key scope names do not contribute to the effective enumeration values, you could use a separate key scope to define "toplevel-01" as a non-root subject and then refer to it in that key scope, e.g.:

<subjectdef keyscope="scope-01" keys="child-subjects-01">
  <subjectdef keys="toplevel-01"/>
</subjectdef>
<subjectdef keys="toplevel-01">
  <subjectdef keys="child-01"/>
</subjectdef>
<subjectdef keys="toplevel-02">
  <subjectdef keys="child-02"/>
  <subjectdef keyref="scope-01.toplevel-01"/>
</subjectdef>
<enumerationdef>
  <attributedef name="attribute-A"/>
  <subjectdef keyref="toplevel-02"/>
</enumerationdef>

Here the reference to "toplevel-01" in the scope "scope-01" is unambiguously a reference to a non-top-level subject definition. 

However, this solution would require duplicating subject definitions just so that you could use the same key name as a top-level category or a descendant value, which seems unnecessary.

Cheers,

Eliot