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

[Eliot Kimber <ekimber@reallysi.com>]

Bruce has it right: if an element specifies both @keyref and @href and the
key reference can be resolved to a resource, then the @href is ignored.

Cheers,

E.

On 8/26/10 10:20 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

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

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com