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

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

Eliot,

Thanks very much for the explanation. That makes a lot of sense, and
more or less matches my understanding. I still think scope, format, and
type should be treated the same as href since they're so tightly
interrelated, but otherwise I feel much better now.

Thanks,

Chris

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Thursday, August 26, 2010 12:35 PM
To: Nitchie, Chris; dita
Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values

The addressing attributes themselves do not propagate.

I think there may be some confusion around the addressing
attributes--attributes involved in defining addresses and characterizing
resources addressed cannot propagate in any sense--they simply establish
one
step in a potentially multi-step chain of addresses.

Thus there is no sense in which a later key definition's addressing
properties *override* the properties specified on an earlier key
definition's addressing properties. Rather, the properties on two stages
in
a multi-stage address are simply effective *on that stage* or they are
not.

In particular, for keydefs that specify both @href and @keyref, there is
no
sense in which the @href attributes of later stages "override" @href
attributes of earlier stages. Rather the basic rule of @keyref
precedence
applies: if any keydef's keyref can be resolved then it's @href is
ignored.

For example, consider this set of key definitions:

<keydef keys="key-01"
  href="foo.xml"/>
<keydef keys="key-02"
  keyref="key-01"
  href="bar.xml"
/>

If resource "foo.xml" exists, then a reference to key "key-02"
ultimately
resolves to the resource "foo.xml" because the key reference from the
second
keydef to key "key-01" can be resolved, so it's @href value is ignored.
It
is not "overridden". It is ignored.

If resource "foo.xml" does not exist, then a reference to key "key-02"
will
resolve to resource "bar.xml" because the key reference to key "key-01"
cannot be resolved, so the fallback behavior applies.

If a reference to key "key-02" itself specified an @href attribute and
neither foo.xml nor bar.xml existed then whatever resource was pointed
to by
that reference's @href attribute would be used, again per the fallback
rule.

Other attributes (possibly all other attributes) propagate using normal
conref semantics, meaning any attribute not specified on a reference
uses
the value specified on the referenced element, if any.

I suspect that the language in what was originally point 26 in the
original
keyref spec was trying to express the fact that addressing attributes
are
not propagated, but it didn't express it well.

I don't think I noticed the problem because I naturally assumed it works
the
way it should work and failed to appreciate the unintended implications
for
non-addressing attributes.

Cheers,

Eliot


On 8/26/10 11:10 AM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

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