[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Action Item: Implications for key definition subelements for topicref-to-topicref key references
|
Denis’ initial question actually involves two different cases: one where the referencing keydef does not have any <keywords> element and one where it has an empty <keywords> element. That raises the question
of whether these two cases would result (or should result) in a different effective value for <keywords> in the referencing topicref. In addition, the 2.0 spec is not 100% clear whether this case should follow the topicref-to-topicref (within-map) cascading and combination rules or the topicref-to-topic cascading and combination rules. Here is an example that I think reflects Denis’ use cases: <map><title>Keywords cascading/combining via keyref</title> <!-- Resource-only keydef that has a <keywords> element with a <keyword> element.
If this was a normal-role topicref then topic topic-01.dita would have the effective <keywords> value of “installation” imposed on to it by the normal map-to-topic metadata cascade rules for <keywords>. --> <keydef keys=”topic-01” href=""> <topicmeta> <keywords> <keyword>installation</keyword> </keywords> </topicmeta> </keydef> <!--This topicref makes a key reference to “topic-01”. It has <topicmeta> but no <keywords> element.
--> <topicref keys=”reference-no-keywords” keyref=”topic-01> <topicmeta></topicmeta> </topicref> <!-- This topicref also makes a key reference to “topic-01”. It has a <keywords> element that has no child <keyword> elements. --> <topicref keys=”reference-with-keywords” keyref=”topic-01> <topicmeta> <keywords></keywords> </topicmeta> </topicref> </map> The question is: There seem to be two defensible answers this question, depending on whether the rules for topicref-to-topicref metadata cascading applies or whether the rules for topicref-to-topic cascading applies. For the
specific case of <keywords> the results are different. The relevant specification language is in two places: 6.4.11, Processing key references on <topicref> elements and 5.3.2, Reconciling topic and map metadata elements. 6.4.11 says: <quote> Content from a key-defining element cascades to the key-referencing element following the rules for combining metadata between maps and other maps and between maps and topics. The combined attributes and content cascade from one map to another or from a map to a topic, but this is controlled by existing rules for cascading, which are not affected by the use of key references. </quote> The ambiguity here is “the rules for combining metadata between maps and other maps
and between maps and topics.” It’s not clear from this statement if the cascade from topicref to topicref via keyref should follow the topicref-to-topicref rules or the topicref-to-topic rules. The rules for cascading of <keywords> is defined in section 5.3.2, in Table 1: <topicmeta> elements and their properties: For the column “How does it apply to the topic” the entry for <keywords> says “Add to the topic” but for the column “Does it cascade to child <topicref> elements?” is says “No”. Therefore, if we interpret a keyref from a topicref to a topciref as using the within-map cascading rules, <keywords> clearly does not cascade from the referenced keydef to the referencing topicref. However, if we interpret the referencing topicref as acting like a topic (“and between maps and topics”) then the <keywords> element would be added to the first topicref in the example above (because there
is no <keywords> element) but not to the second, which has a <keywords> element. In my reading of the sections on metadata cascading generally, I do not see anything about the combining of metadata elements, only metadata attributes that take multiple values. Thus it’s not entirely clear
what the intent is for something like <keywords> that can take multiple values—do they combine when cascading from topicrefs to topics or do they not? It makes sense to me that <keywords> would cascade from a referenced keydef to its referencing topicref (and, by implication, to the topic ultimately referenced), that is, the same result you would get if
the referenced keydef was a normal-role topicref. This also points up that there’s a little bit of a potentially confusing back-and-forth with the metadata, where the topicref-to-topicref cascading is in the direction from referenced keydef to referencing
topicref but then is from the direction of referencing topicref to referenced topic, reflecting the effective metadata of the referencing topicref after applying cascading rules between the referenced keydef and referencing topicref: <topicref keyref=”topic-01”> -> <keydef keys=”topic-01” href="" -> <topic id=”topic-01”>…</topic> Here the cascading process is:
Conceptually, we can imagine that the chain of topicrefs from the initial <topicref> to the topicref that references the topic are “collapsed” into a single effective topicref that reflects the cascading of
metadata from the end of the chain to the start of the chain. This effective topicref then imposes its effective metadata onto the target topic just as it would if it had been directly authored as a single topicref. As a TC we need to decide whether the metadata cascade from referenced keydef to referencing topicref uses the topicref-to-topicref rules or the topicref-to-topic rules or some new rule we haven’t defined. My vote at the moment is that it should be the topicref-to-topic rules, reflecting the fact that the initial topicref serves as a proxy for the ultimately referenced topic and that with this behavior the result
can be the same as if the keydef was a normal-role reference to the topic. In addition, it may be necessary to clarify the metadata combining rules for the <keywords> case: does it act like an attribute that takes multiple values or is it always just a “cascade if no <keywords> element
is present in referencing topicref”? If combining applies, that implies that the @combine attribute also applies, which doesn’t seem to be accounted for in the current 2.0 language and is probably a level of complication we’ve actively avoided
to date. Cheers, Eliot _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]