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

["Kerry, Richard" <richard.kerry@xxxxxxxx>]

Thank you all for this.
I had a vague recollection of coming across something like this in the dim and
distant past.

I think my data is likely to be "not well-controlled".


Now back to studying the rest of the solution (and other things).


Appreciatively,
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: 29 August 2012 17:27
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-29 16:16 +0000, Kerry, Richard wrote:
>Regarding Ken's solutions from last Wednesday (repeated below), why is it :
>
><xsl:analyze-string select="$thisAlarm/@equipment"
>regex="^{$thisGroupedAlarm/@equipment}$">
><xsl:matching-substring>
><xsl:for-each select="regex-group(1)[normalize-space(.)]">
><xsl:attribute name="found-key" select="."/>
></xsl:for-each>
></xsl:matching-substring>
></xsl:analyze-string>
>
>rather than
>
><xsl:analyze-string select="$thisAlarm/@equipment"
>regex="^{$thisGroupedAlarm/@equipment}$">
><xsl:matching-substring>
><xsl:attribute name="found-key" select="regex-group(1)"/>
></xsl:matching-substring>
></xsl:analyze-string>
>
>?
>
>What does the [normalize-space(.)] predicate do for us ?

I am positioning the context to be the regex-group(1) string only if
that string is non-empty (or, at least, not made entirely of
white-space characters; if you want found white-space preserved, then
replace normalize-space(.) with string(.) instead).  If the string is
empty, then I don't want to create the attribute.  If the string is
non empty, then I want to create the attribute with that string
value, which is now the context.

In your example, matching "1 Alarm" that does not have any groups
will create the empty attribute found-key="" ... which wasn't in your
example of what you wanted.  I understood you to want found-key=
suppressed if there were no search strings in the content.

So your suggested code will create the empty found-key="" and mine will not.

I hope this is helpful.

. . . . . . . . . . Ken


________________________________________
From: Michael Kay [mike@xxxxxxxxxxxx]
Sent: 29 August 2012 17:29
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Pattern Matching in XSl - find groups defined in one Xml in
another Xml.

I didn't follow the original discussion, but the for-each version avoids
creating the attribute if it would be empty.

Michael Kay
Saxonica

________________________________________
From: Wendell Piez [wapiez@xxxxxxxxxxxxxxxx]
Sent: 29 August 2012 17:29
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Pattern Matching in XSl - find groups defined in one Xml in
another Xml.

Richard,

This is an idiom we use to filter out values that have whitespace only.

normalize-space(' ') returns '', which (coerced to a Boolean
false) fails a test.

So regex-group(1)[normalize-space(.)] returns an empty sequence when the
value of regex-group(1) is an empty string or only whitespace.

Ken is going to a little extra trouble here to avoid getting

found-key=" "

when $thisGroupedAlarm/@equipment has " ".

In other words, it's defensive programming of the sort you learn to
write when you have to handle data sets that are not well-controlled (an
unfortunate fact of life). You can skip it if you know that your data is
good, and won't be throwing up such cases, or more generally if
garbage-in/garbage-out is fine for you.

Cheers,
Wendell