OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Attribute cascade proposal

I think I agree with David that it needs to be possible to specify the merge
behavior on a per-condition basis on any element where cascading would

Without that level of control, the mechanism would be insufficiently

There should be a way to define blanket merging rules for the case where you
simply want everything to behave the same way, but that can't be the only

Option (3), processor decides, is a non-starter for me because you'd have no
way to predict behavior. I don't like options (1) and (2) for the same
reasons everyon else doesn't like them.



On 5/21/13 5:07 PM, "Helfinstine, David" <dhelfinstine@ptc.com> wrote:

> Greetings,
> I like #4 in general also:
> #4 Rather than a blanket policy it might be nice to be able to say
> cascade="NOMERGE audience otherprops specAttrFromProps ZIPPERMERGE product". I
> wouldn't want to presume that a customer would always want all or nothing, nor
> that all would want to have the same cascade. The idea above is the uppercased
> items are the tokens and those things that come after would apply. Those that
> weren't specified would work the default way of merging.
> If it is set on a map by map basis, the DITA 1.2 spec says this:
>         As with values that cascade within a map, the cascading is additive if
> the attribute permits    multiple values (such as @audience). When the
> attribute only permits one value, the cascading   value overrides the
> top-level element.
> So there would have to be some addition as to which policy wins ( probably the
> outer map setting as with other overriding items) but that needs some
> consideration as mentioned.
> FYI:
> Some releases back we realized that many of our customers had a need to
> specify the behavior that you described. These customers were often using our
> "profiling" feature which depended on profiling attributes NOT merging. The
> way that Chris mentioned was a way to do this via specialization (yes, the
> name is backwards) but many customers wanted out of the box behavior also.
> Currently we provide a "global" out of the box way for customers to set a
> policy of whether attributes that normally merge will merge or not merge.
> Making this standardized would be great.
> Thanks all.
> - Dave H.
> Dave Helfinstine
> DHelfinstine@ptc.com
> -----Original Message-----
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf
> Of Chris Nitchie
> Sent: Tuesday, May 21, 2013 2:32 PM
> To: 'Robert D Anderson'; 'dita'
> Subject: RE: [dita] Attribute cascade proposal
> 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
> ---------------------------------------------------------------------
> 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

Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
Book: DITA For Practitioners, from XML Press,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]