Greetings,
I agree with your assessment. Hitting a “nomerge” should not mean for a processor to go back and try to unravel what might have merged, but to use the calculated
value in no merge from that point on. So if the next nested topicref had <topicref platform=”B”> only the “B” would make it on further.
Thanks.
- Dave H.
Dave Helfinstine
DHelfinstine@ptc.com
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
On Behalf Of Robert D Anderson
Sent: Tuesday, March 25, 2014 2:29 PM
To: dita
Subject: [dita] Cascading attribute metadata that merges (or not)
Hi,
I'm looking at comments in the "metadata cascade" topic, and realized that the definition of the new @cascade attribute left at least one case unspecified:
https://ditaweb.com/oasis-dita/#/00028678-DB.00028004-DB.Cascading%20of%20attributes%20and%20metadata%20in%20a%20DITA%20map
Specifically, what is the evaluated value for @platform on the second topicref in this scenario?
<map platform="A" cascade="merge">
<topicref platform="B">
<topicref cascade="nomerge">
When the cascade is evaluated, the @platform value for <map> cascades to and is merged with @platform="B" on the first topicref, resulting in an implied value of platform="A B".
For the second topicref - does this already merged value "A B" cascade? Or does the "nomerge" token mean that only the most recent (unmerged) value "B" cascades? One of these must be true (@cascade
does not turn off the cascade entirely, it only controls whether cascading values merge or not).
I think that the already-merged value cascades to this topicref. Essentially, the meaning of the cascade is that the first topicref applies to both platform A and platform B. It is equivalent to
having an explicit setting of platform="A B" on that element. Thus, I think that once the cascading is calculated, the sample above is equivalent to the following:
<map platform="A" cascade="merge">
<topicref platform="A B">
<topicref platform="A B" cascade="nomerge">
In other words, the algorithm here is essentially:
-
Establish @platform for <map> -- the value "A" is explicit.
-
Establish @platform for the first <topicref> -- using the rules we've laid out, the value is "A B" (cascading "A" from parent merges with explicit "B")
-
Establish @platform for the second <topicref> -- cascading "A B" from parent is used because there is no @platform value specified here. We don't ignore the already-established "A B" value from
the parent.
My initial thought was just to update the topic with this example, but I am running it by the TC as a sanity check because I'm sure the example was not discussed previously.
Thoughts?
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)