[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Alternative to proposal 13056
Hi, Item 13056 in the proposal list has been waiting on me for a while now. That item requests: Add more conditional attributes to base DITA so that people don't have to specialize just because they need more than 4 conditional attributes. Eg. add attributes called otherprops2, otherprops3, otherprops4, otherprops5, and otherprops6. I am worried about the idea of having att2, att3, etc for a few reasons: 1. When do we stop - is it enough to have 3? 4? 6? Will the next DITA need product2 and product3? 2. How do we define these? I'm picturing "otherprops5: see definition of otherprops4" 3. Bigger problem is the confusion with authoring and filtering. If "a" and "b" are filter tokens - how does the author keep straight that those values are only for otherprops3? If they share with anther team that uses otherprops2, how would filtering work -- do they need to filter "a" and "b" from all 6 attributes just in case? So, as an alternative, I'd like to suggest something similar to our existing syntax for specialized attributes. Hopefully we can discuss this at the next TC meeting. Background: DITA 1.1 defined how to generalize specialized attributes. For example, the props specialization widget="a b" would be generalized to props="widget(a b)" The four existing filter attributes audience, product, platform, and otherprops were not reconfigured to be specialized attributes because of concerns for backwards compatibility. I believe that's still the case. Rather than adding in new attributes, I'd like to suggest making the existing "generalized" syntax legal in the 4 old attributes. For example: otherprops="group1(a b) group2(c d e)" or product="database(db2 oracle) appserver(WAS5 WAS6)" The groups would be processed exactly the same as groups inside @props -- that is, they are each treated as an individual attribute for the purposes of filtering. Today, @product="db2 oracle" cases an entire element to be removed when those two are excluded, regardless of the other attributes. In the sample above, excluding db2 and oracle would have the same effect, regardless of the WAS5 and WAS6 settings. One discussion item would be whether filter rules would need to exclude product=db2 or if they would say to exclude database=db2. Some advantages to this approach: *. Processors that work with DITA 1.1 level @props should be familiar with the syntax *. Avoids adding new attributes that overlap (otherprops2, 3, etc) *. Allows extension for audience, platform, and product; our users already have a requirement for database and appserver groups (among others), all to indicate a different set of product values *. Similar design to accepted proposal 13074, which also suggests direct authoring of groups (specifically within @props) Thanks - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]