RE: [dita] Attribute cascade proposal

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

Arbortext has an a proprietary approach to this, too, but it's done in the
definition of the attribute specialization, and not specified in the map, so
it may not work for all the necessary use cases. If an attribute is a
specialization of props-nooverride - that is, its @domains token looks like
"a(props props-nooverride attrName)", then for that attribute - that
attribute only, and all instances of that attribute - new values on child
branches/elements override values inherited from parent branches/elements,
instead of merging. (Yes, the naming is awkward and probably backwards.)
This wouldn't handle the specific example here, because @platform wouldn't
be specialized from props-nooverride, and you can't make some instances of
'nooverrides' attributes merged and others non-merging, but it seems to have
worked well enough for our purposes.

Chris

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Tuesday, May 21, 2013 3:17 PM
To: dita
Subject: [dita] Attribute cascade proposal


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