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:]
Sent: Tuesday, May 21, 2013 3:43 PM
To:
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
