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

["Nitchie, Chris" <cnitchie@ptc.com>]

Bruce,

Your understanding matches mine exactly (which is no small relief).  But
Eliot's message
(http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201008
/msg00109.html), which I may well not understand correctly, seemd to
state that propagation should work the other way. That is, if an
attribute is specified on both a key reference and the matching
effective key definition, then the value on the key reference should be
the effective value for processing, and the value on the key definition
does not apply.

Eliot, I see from the archive (I haven't gotten the message in my inbox
yet) that you concurs with Bruce, which is an even bigger relief, but
I'm not sure how to square that with your earlier message.

Chris

-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] 
Sent: Thursday, August 26, 2010 11:20 AM
To: dita
Subject: RE: [dita] DITA v1.2 Review | Propagating attribute values


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


---------------------------------------------------------------------
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