RE: [dita] Attribute cascade proposal

["Chris Nitchie" <chris.nitchie@oberontech.com>]

I agree, though I'd want to allow it anywhere @props is allowed, not just on
topicrefs.

Chris

-----Original Message-----
From: Kristen James Eberlein [mailto:kris@eberleinconsulting.com] 
Sent: Tuesday, May 21, 2013 3:43 PM
To: dita@lists.oasis-open.org
Subject: Re: [dita] Attribute cascade proposal

I like #4. It would solve some of my client problems nicely.

Best,
Kris

Kristen James Eberlein
Principal consultant, Eberlein Consulting Co-chair, OASIS DITA Technical
Committee Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 5/21/2013 3:16 PM, Robert D Anderson wrote:
> Hi,
>
> As with the branch filtering item, I'm hoping to get some initial TC 
> feedback on expected direction with the cascade item.
>
> Basic use case is a map like the following, applies to 3 platforms:
> <map platform="mac win linux">
>   ....
>      <topicref href="nested-branch.dita" platform="mac">...</topicref>
>   ....
> </map>
>
> Per the spec today, when platform cascades, values combine. This means 
> if I
> (accurately) indicate that my map applies to 3 platforms, I cannot 
> then restrict one section of that map to a specific platform - values 
> combine, so that even my mac-only branch is treated as mac/win/linux.
>
> I expect there are many cases where this is valid and proper - and 
> applications have implemented this - so we cannot simply change the 
> behavior. The other option is to provide author or tool control over 
> the behavior. Potential solutions considered:
>
> 1) Extend @lockmeta to add some control over whether attributes get
merged.
> I don't like this because it's on <topicmeta> -- so to find out if 
> @platform cascades, we might have to check parent/topicmeta/@lockmeta, 
> then parent/parent/topicmeta/@lockmeta, and so on -- too indirect and 
> likely to be confusing.
> 2) Add a token to attributes. For the nested case above, I could say 
> something like platform="#override# mac" or similar - indicate this 
> does not merge with ancestor values. Feels clunky and likely to be 
> painful to use, possibly to implement.
> 3) Change the spec to make this optional - tools can implement cascade 
> with or without merging, possibly through some tool option. Have not 
> really considered this fully, and could mean you get very different 
> behavior in different apps.
> 4) Add a new attribute in maps, something like cascade="merge | nomerge".
> Would likely leave this open to other values, with 2 (or more) 
> predefined tokens - similar to how chunking works - allowing tools to 
> expand their support to new types of merging. Default could be the 
> predefined token "merge", to keep current behavior. Not sure if this 
> attribute would itself cascade / override lower values, not fully thought
out yet.
>
> At the moment I'm leaning towards the last option in that list. The 
> first two seem too complex / difficult to use. The third I'd be 
> willing to consider but for now at least I think the goal is to have 
> this a standardized behavior, which pushes us to #4.
>
> Thoughts?
>
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
>
>
> ---------------------------------------------------------------------
> 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