Hi Bob,
The difference here (and this is new with the grouping syntax) is that each group on its own is treated the same as an attribute. So the AND behavior that traditionally applies between attributes also applies between attributes within a group.
The reasoning is really the same as the original reasoning for AND between attributes. In the original case, if I have something that applies to 2 products and 4 audiences, then when I exclude those 2 products entirely, the information is useless (regardless of audience).
With groups, we have different categories of products that are really as different as the older product/audience distinction. (In our beta usage, we can think of it as two top-level branches of the product taxonomy). In the sample below, the content in question applies to databases that run on servers. Therefore, the content is specific to database "newDB", when running on server "mySERVER". If I've filtered out the database portion, then this content is meaningless - it doesn't matter how many servers are still valid if I'm not working with the database in question.
In a perfect world, these would both be specialized attributes - specialized directly from product. However, @product is not and cannot be specialized, in order to retain backwards compatibility with DITA 1.0 through 1.2. One reason that this syntax matches the generalized attribute syntax is so that in DITA 2.0, there's at least a decent chance that @product will become a specialized attribute, in which case these suddenly become generalized attributes. One could (at that point) clean up the content by moving these from this:<p product="database(newDB) appserver(mySERVER)">
to this, which still keeps the connection to @product through specialization:<p database="newDB" appserver="mySERVER">
Does that help?
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
Bob Thomas ---01/24/2015 14:44:31---While participating the conditional processing targeted review, I went to the <val> element in the l
From: Bob Thomas <bob.thomas@tagsmiths.com>
To: dita <dita@lists.oasis-open.org>
Date: 01/24/2015 14:44
Subject: [dita] Problems with the "figure" under <val> in the Language Specification
Sent by: <dita@lists.oasis-open.org>
While participating the conditional processing targeted review, I went to the <val> element in the language specification (3.9.1 when the current spec in SVN is produced) for guidance on using groups in DITAVAL. The last bullet point under Figure 83: DITAVAL with conditions for groups reads:
<p product="database(newDB) appserver(mySERVER)"> is filtered out, because the token
"newDB" is excluded when found in the database group. The entire "database" group on this paragraph
evaluates to "exclude", so the element is excluded, regardless of how the "appserver" group evaluates.
I dispute the statement that I highlighted. It seems clear to me that if appserver(mySERVER) evaluates to "include", then the element would be included regardless of how the database() group evaluates. My understanding is that Boolean OR behavior is in effect with respect to "include" when determining the net value of an individual profiling attribute, and that Boolean AND behavior for "include" only occurs when comparing the net values on a collection of profiling attributes that have been assigned within the same element.
Best Regards,
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)