At 2012-08-23 10:07 +0000, Kerry, Richard wrote:
Thinking about it overnight I think I could get the search done by
using two passes. Firstly the RE (or key) based search we've
already seem some examples of. And then a second pass to check
whether the groups have been found in thier entireties.
I'm about to try this latest example of yours. At a very quick
glance I think I can see two passes.
Not quite ... the "second" pass is only going over those groups that
were found, not all groups. So it isn't really a second pass over
all of the data.
Note that my first focus is from the group level, because only there
can you tell if for a given area all of the members of the group are found.
Then I go over the area alarms, finding which of the found groups (if
any) each alarm was in. There is no need to go over all groups, only
over the found groups. And if there are no found groups, there is no
loop for the area alarms.
In the classroom I see students take traditional programming
approaches to issues that are best declared. Why best? Because then
the processor can do the optimization and not be hobbled by the
stylesheet writer's implementation of the algorithm.
For an example, take the declarative approach in finding out which
groups are fully populated by the area alarms:
<xsl:variable name="foundGroups" select="$groupedAlarms
(:there can be no mis-matches:)
[every $groupAlarm in alarm satisfies
some $areaAlarm in $thisAlarmArea/alarm
satisfies matches( $areaAlarm/@equipment,
concat('^',$groupAlarm/@equipment,'$'))]"/>
This takes advantage of the two standalone quantified expressions
that return true()/false() values:
every tuple-list in set satisfies boolean
(all tests must be true() in order to return true())
and
some tuple-list in set satisfies boolean
(any test must be true() in order to be true()
In my case, I've nested the "some" expression to return the boolean
evaluation for the "every" expression. Having the variables
available in scope made the "some" evaluation straightforward and
self-documenting.
Note the processor can stop evaluation of the "every" expression as
soon as it hits a false() value, and it can stop evaluation of the
"some" expression as soon as it hits a true() value. If the
stylesheet writer takes a programming approach and replaces the above
with an algorithmic walking of the tree, even with the use of a
function call, it could end up doing a lot more work than the processor would.
I hope this is helpful.
. . . . . . . . . . . . Ken
--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--