RE: [dita] DITA v1.2 Review | Propagating attribute values

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

I'm confused. I may be completely misunderstanding what you're saying,
Chris, but here's my understanding.

> [...] if I have both @href and 
> @keyref on an element, and the key definition also has an 
> @href, the @href on the reference wins?  Or is @href an 
> exception?  And if @href is an exception, then shouldn't 
> @scope, @format, and @type be also?
> 
> Say you had this xref:
> 
> <xref keyref="website" scope="external" format="html" 
> href="http://www.oasis-open.org";>website</xref>
> 
> Is there no way to change where this xref points by defining 
> 'website'? If that's the case, then the language in the spec 
> about falling back to the href on the referencing element is 
> probably irrelevant.

In my simple brain I thought that "the @href on the referencing element"
that also has a @keyref is _always_ irrelevant unless the definition of
the key name fails to resolve to a resource. It's a fallback. That's
what "the language in the spec about falling back to the href on the
referencing element" means. It's at 2.1.3.4.3.2 "Using keys to address
DITA elements":

        If both @keyref and @href attributes are specified 
        on an element, the @href value must be used as a 
        fall-back address when the key name is undefined, 
        and should be used as a fall-back address when the 
        key name is defined but the key reference cannot 
        be resolved to a resource.

I'm not sure where the generalization "the reference wins" comes from.
Several references are in play here. The @href on the referring element
'wins' only if the reference specified in the key definition fails.

In your example above, the key name "website" is set to the @href
reference given in the effective <keydef> or <topicref> that defines
that key name. If you want to change what it points to, you include the
topic that contains that <xref> in a map in which some other definition
of the key name "website" comes first. If you move it to a map in which
the key name "website" is not defined, or if for some other reason that
key name does not resolve to a URI, then the <xref> resolves to
href="http://www.oasis-open.org"; (the @href in the referring element) as
a fallback.

> The spec also states [at 2.1.3.4.3.3 "Processing key references"]:
> 
> ====
> When a key definition has no @href value and no @keyref 
> value, references to that key will not result in a link, even 
> if they do contain an @href attribute of their own.
> ====
> 
> Is this a special case? It seems to run counter to the idea 
> that the referencing element wins.

A reference to that key is a reference to null. If you include the topic
with your example <xref> in a map in which the key name "website" refers
to null, then there is no link at that location in output. Further, if
empty elements in that topic use @keyref with that key name to pull in
content, then in this map where the key name "website" refers to null
those elements are dropped from output. I don't remember, but I bet
there was discussion of use cases for this behavior.

The language here (2.1.3.4.3.3 Processing key references) clouds the
distinction between the referring element and the references (@keyref,
@href, etc.) that the referring element contains. This is how the spec
reads now:

	When a key definition has no @href value and no @keyref value, 
	references to that key will not result in a link, even if they 
	do contain an @href attribute of their own.

The word "they" is ambiguous. This is how I think it should read:

	When a key definition has no @href value and no @keyref value, 
	references to that key will not result in a link, even if the 
	referring element contains an @href attribute of its own. 

If I'm out to lunch here, I expect to be corrected in short order, but I
think I'm understanding this correctly.

	/Bruce