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: Alternative to proposal 13056


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
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)"
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]