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

[Eliot Kimber <ekimber@contrext.com>]

Ah, I clearly haven't paid enough attention to the @cascade feature. So
forget that comment.

Cheers,

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




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

>Hi Eliot,
>
>I hesitate to respond to agreement, but I just want to clarify:
>> With the new @cascade element a map author could turn on cascading of
>> either element if they wanted it.
>
>The @cascade attribute is defined as only dealing with attributes. It's
>specifically intended to handle the merging or not merging of attribute
>values; it does turn cascading itself off even for attributes.
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
>
><dita@lists.oasis-open.org> wrote on 04/23/2015 14:50:00:
>
>> From: Eliot Kimber <ekimber@contrext.com>
>> To: Robert D Anderson/Rochester/IBM@IBMUS, DITA TC
>><dita@lists.oasis-open.org>
>> Date: 04/23/2015 14:50
>> Subject: Re: [dita] Cascading of <source> and <othermeta> in maps
>> Sent by: <dita@lists.oasis-open.org>
>> 
>> 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-dit
>>>am
>> >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/)
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> 
>