Re: [dita] Cascading of <source> and <othermeta> in maps

[Eliot Kimber <ekimber@contrext.com>]

It makes sense to me that <source> would *not* cascade as its purpose is
to indicate the source of the resource referenced by the topicref and
doesn't inherently imply the source of any descendant topicrefs.

Likewise, I've always equated <othermeta> to <data> and agree that they
should have the same cascading behavior.

With the new @cascade element a map author could turn on cascading of
either element if they wanted it.

Cheers,

Eliot
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 4/23/15, 1:50 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

>Jarno Elovirta pointed out to me today (based on an issue from a DITA-OT
>user) that we have conflicting information in the spec about cascading
>metadata - specifically the two elements <source> and <othermeta>. This
>language is in DITA 1.2 and remains in the latest DITA 1.3 draft.
>
>The following topic lists <source> and <othermeta> as metadata elements
>that cascade within a map:
>http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/cascading-in-a-ditam
>ap.html
>
>The following topic is more comprehensive and covers every metadata
>element in the map, listing whether it cascades within a map or from map
>to topic. It says that <source> and <othermeta> cascade from <topicref>
>to a referenced topic, but that they do not cascade within a map:
>http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/reconciling-topic-an
>d-map-metadata.html
>
>I worked quite a bit on that second topic in DITA 1.2 so that's what I
>was most familiar with - I thought that these two elements did not
>cascade within a map. I vaguely remember that <othermeta> was discussed
>during the 1.2 process, and was grouped with <data> as a generic metadata
>element that cannot be assumed to cascade. I don't remember any specific
>discussion of <source>.
>
>Given that the two topics directly contradict each other, we need the TC
>to weigh in on which is correct. Ideally we can also get rid of this
>duplicate info in the spec. Until now it has been in the back of my mind
>as one of those things I'd like to fix but may leave alone, given our
>time constraints and given that the two topics existed in 1.2.
>
>Thanks,
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)