OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  Attribute cascade proposal

    Posted 05-21-2013 19:18
    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/ )


  • 2.  RE: [dita] Attribute cascade proposal

    Posted 05-21-2013 19:33
    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


  • 3.  RE: [dita] Attribute cascade proposal

    Posted 05-21-2013 21:08
    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


  • 4.  Re: [dita] Attribute cascade proposal

    Posted 05-22-2013 10:31
    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 apply. Without that level of control, the mechanism would be insufficiently granular. 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. 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. Cheers, E. 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 > > >


  • 5.  Re: [dita] Attribute cascade proposal

    Posted 05-22-2013 13:12
    > 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 > apply. > > Without that level of control, the mechanism would be insufficiently > granular. Yep - that's the main reason I think any attribute controlling this should be CDATA - not limited to a binary choice like "merge" or "nomerge" (though I think at least those two core values are required). Ignoring syntax, I can easily picture an implementation like David's with something like "TOKEN-A audience TOKEN-B platform product". > 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. Agreed. Mostly just listed those to show what had already been considered (and would likely be suggested), and why they were not my primary suggestion. Thanks - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit ( http://dita-ot.sourceforge.net/ ) Eliot Kimber <ekimber@rsicms.com> wrote on 05/22/2013 06:30:15: > From: Eliot Kimber <ekimber@rsicms.com> > To: "Helfinstine, David" <dhelfinstine@ptc.com>, Chris Nitchie > <chris.nitchie@oberontech.com>, Robert D Anderson/Rochester/ > IBM@IBMUS, dita <dita@lists.oasis-open.org>, > Date: 05/22/2013 06:37 > 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 > apply. > > Without that level of control, the mechanism would be insufficiently > granular. > > 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. > > 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. > > Cheers, > > E. > > 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 > > > > > >


  • 6.  Re: [dita] Attribute cascade proposal

    Posted 05-21-2013 19:43
    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


  • 7.  RE: [dita] Attribute cascade proposal

    Posted 05-21-2013 20:33
    I agree, though I'd want to allow it anywhere @props is allowed, not just on topicrefs. Chris