[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Cascading of <source> and <othermeta> in maps
I had an insight while reading this discussion. The term "cascade"
is processing oriented; there is no cascade without a specific
implementation behavior somewhere. So when I looked at the table of
elements under the "Does it cascade" column, I suddenly realized
that the Yes/No values are defining processing flags, not intrinsic
properties of the elements (what the Spec ought to be defining). And
the properties I see behind the Yes/No values are Mutable (meaning
programmatic processing can influence the effective value of the
element) and Immutable (meaning the element represents a persistent
value that should change only by editorial rather than by
programmatic process). As a result, I see more clearly why <source> and other metadata elements are immutable--their values are warranted to persist, and are auditable in the sense that they represent facts rather than states (facts don't change; states do). This fits in with seeing DITA as a data model rather than in terms of processing. I don't suggest changing any wording for now, only that this viewpoint might help in coming up with responses to future questions about the cascade.
Don R. Day
Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday Twitter: @donrday About.me: Don R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?" --T.S. Eliot On 4/23/2015 3:43 PM, Eliot Kimber
wrote:
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 aDITA-OTuser) 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 frommapto 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 genericmetadataelement that cannot be assumed to cascade. I don't remember anyspecificdiscussion of <source>. Given that the two topics directly contradict each other, we need theTCto 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 mymindas 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--------------------------------------------------------------------- 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]