[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]