[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Pattern Matching in XSl - find groups defined in one Xml in another Xml.


Subject: RE: [xsl] Pattern Matching in XSl - find groups defined in one Xml in another Xml.
From: "Kerry, Richard" <richard.kerry@xxxxxxxx>
Date: Thu, 23 Aug 2012 10:07:16 +0000

>Richard, given that groups are defined in the groups.xml file, where is the
flexibility needed for a function?

A function wasn't my idea !
(Wendell's I think)

>Isn't the flexibility found in the groups.xml file?

I think it probably is.


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.


Hopefully,
Richard.


Richard Kerry
BNCS Engineer
T: +44 (0)20 82259063
M: +44 (0)7812 325518
Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
richard.kerry@xxxxxxxx
uk.atos.net

This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its integrity
cannot be secured on the Internet, the Atos group liability cannot be
triggered for the message content. Although the sender endeavours to maintain
a computer virus-free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.

________________________________________
From: G. Ken Holman [g.ken.holman@xxxxxxxxx] on behalf of G. Ken Holman
[gkholman@xxxxxxxxxxxxxxxxxxxx]
Sent: 22 August 2012 18:29
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx; xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Pattern Matching in XSl - find groups defined in one  Xml
in another Xml.

At 2012-08-22 12:21 -0400, Wendell Piez wrote:
>Hi again,
>
>On 8/22/2012 10:42 AM, G. Ken Holman wrote:
>>Ah, forgive my oversight. I missed the "all-ness" of the requirement.
>>
>>>I haven't yet worked out how your various solutions work so I can't
>>>yet consider how I might make these changes.
>>
>>Sounds like Wendell is on the right track and that his work would lead
>>to a more successful result since I missed such an important requirement
>>in my haste.
>
>Hey no fair! Especially since I didn't address that (or any)
>requirement directly. I only offered a way to refactor that isolates
>the matching test in one place (a function), where it can be
>understood and adjusted more easily.

Ha!  Okay ... I'll take back the problem for a solution.

Mind you, having finally solved the issue (I think!  Please tell me
if I'm wrong!), I ended up not feeling strongly about using a
function anywhere.

Richard, given that groups are defined in the groups.xml file, where
is the flexibility needed for a function?  Isn't the flexibility
found in the groups.xml file?

I've taken what I think is a very time-saving approach, first finding
the groups that are in the area, and only then walking over the area
alarms comparing each to the found groups.  That way I'm not
re-finding the found groups for every alarm, which I think is what
the function was doing.

I just can't figure out where function flexibility is needed ... I
cannot see what needs to be tweaked that isn't simply in the groups.xml file.

A transcript is below of what I hope is helpful this time
around.  Please let me know where I may have misunderstood the
requirements, especially for flexibility.  I hope the embedded
comments are helpful.

Apologies, again, for having jumped to the wrong solution in my earlier post.

. . . . . . . . . . . Ken


Current Thread
Keywords