[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Pattern Matching in XSl - find groups defined in o
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: 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: 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: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|