RE: [xsl] Novice Question - matching entire text children - RESOLVED

Subject: RE: [xsl] Novice Question - matching entire text children - RESOLVED
From: "David Lee" <dlee@xxxxxxxxxxx>
Date: Mon, 20 Dec 2010 20:14:51 -0500
This thread provided such great responses.   Thank you all.
I usually don't lurk on this list because I *AM* a total Novice in XLST ...
(but not in other XML technology).
I guess I'm one of those people Michael mentioned that isn't in the "Loves
XSLT" category :)
"Novice" is relative :)  I just used it in the subject to make it perfectly
clear that almost certainly whatever I was doing was wrong 
(rather than the assumption that the processor was wrong).

But I'm trying.   I even the "Tome" on my desk and I actually open it from
time to time.

Anyway to quest all your thirst for information.

I Took the strip-space directive and voila those nasty text nodes came back
This time armed with more knowledge I was able to resolve it

<drum roll>

I had an 
	<xsl:apply-tempaltes match="text()">

on a NON-terminal node !!! 

It was matching all the blank space between child elements (indented XML of
course !).

Now I know I need to use the schema information to not do this except on
nodes with only text content.
And still need to think about how to handle comments.
Honestly I would have thought comments would be stripped by the data model
but I guess not.   Back to the books !

Again, that's for all your helpful and friendly help.

David A. Lee

-----Original Message-----
From: David Lee [mailto:dlee@xxxxxxxxxxx] 
Sent: Monday, December 20, 2010 9:31 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Novice Question - matching entire text children

Thanks all...
This gives me something to go on.
I did "try" mikes suggestion in a novice way 
" is to use the string-value of the element node, rather than its text node

by writing:

<template match="NODE/string()" >

Which should obviously work right ?  Matches the entire string contents of
NODE concatenating silly chunked up adjacent text and removes commands and
PI's ...

Ha silly me.

I will take to heart the reason WHY I think I need to match on text() ...
maybe I don't.
I won't go into details right now, I'm looking more in directions to
investigate and learn rather than solutions to my problem.

Thanks all

David A. Lee

-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
Sent: Monday, December 20, 2010 9:20 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Novice Question - matching entire text children

In principle, an element node is not allowed to have two adjacent text 
node children, so unless there are comments or processing instructions 
breaking up the text, it should be delivered as a single node.

However, DOM does allow adjacent text nodes, and some processors work on 
a DOM tree as input, and I suspect some processors do not always 
amalgamate adjacent text nodes as they should.

In any case, it's a good idea to make sure that your code still works if 
someone puts a comment in the middle of the text, so it's best not to 
assume that all the text of an element is in a single node. Usually the 
best way of doing that (unless you are dealing with mixed content) is to 
use the string-value of the element node, rather than its text node 

Michael Kay

On 20/12/2010 13:09, David Lee wrote:
> XSLT 2.0
> I have a problem (probably my own misuse of XSLT) but I run into cases
> <xsl:template  match="NODE/text()">
> .
> </xsl:template>
> can match more then once in a row.   I have not debugged this yet to
> determine if something more complex is really the culprit (probably is),
> and the text nodes matched seem to be whitespace  " \n\t .."
> But before I really start digging maybe someone could tell me offhand what
> the *expected* behaviour is ?
> If I have an element lik
>                  <ELEM>
>    some
> Text
> Here</ELEM>
> is
> <xsl:template  match="NODE/text()">
> *supposed* to be called once and only once with the entire text children
> is it possible that it is called multiple times with chunks of data as the
> processer sees fit. ?
> I know just enough to hurt myself by knowing that in various data models
> the CHARACTERS (aka text()) can be arbitrarily chunked but I don't know
> know where to look) to answer the above definitatively .
> Thanks for any suggestions
> ----------------------------------------
> David A. Lee
> dlee@xxxxxxxxxxx
> ----------------------------------------
> David A. Lee
> dlee@xxxxxxxxxxx

Current Thread