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