OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


Eliot Kimber, Owner
Contrext, LLC

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:
>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:
>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.
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]