On Mon, Dec 31, 2007 at 07:21:45PM +1000, Alexander Zangerl wrote:
> On Su,n 30 Dec 2007 20:43:26 +0200, Niko Tyni writes:
> >The documentation of XML::XPath::findnodes_as_string states it "returns
> >the nodes found reproduced as XML", and the W3C XML Path Language
> >specification section 5.7, "Text Nodes" [1] contains this:
> >
> > NOTE: When a text node that contains a < character is written out
> > as XML, the < character must be escaped by, for example, using &lt;,
> > or including it in a CDATA section.
> 
> you do realize that last part of the sentence talks about
> including it in a CDATA section and thus voids your argument?

Hm, so would you expect the findnodes_as_string() return value in your
example include the CDATA markup then?

sdlfkkskdfjl 
<![CDATA[cdata grind <hallo> sdsdfsdf]]

As I understand this, that's the other option available. In particular,
returning unquoted text like findvalue() does would not be "reproducing
the node as XML." Sorry if I'm being dense.

> as per the xml specs
>    http://www.w3.org/TR/1998/REC-xml-19980210#sec-cdata-sect
> CDATA is sacrosanct and nothing within it can be escaped, ever:
> 
>       Within a CDATA section, only the CDEnd string is recognized as markup,
>       so that left angle brackets and ampersands may occur in their literal
>       form; they need not (and cannot) be escaped using "&lt;" and "&amp;".

My thinking was that the return value is not text "within a CDATA
section", but rather (more or less) standalone XML, so this wouldn't
apply.

I always thought CDATA sections are just a way of escaping the
inconvenient characters in input, and not sacrosanct entities that must
stay untouched. How absolute is this? If an XML filter gets input like

 <![CDATA[<test> string]]

and outputs

 <![CDATA[<test>]] string

is it doing the wrong thing?

> >I'm thus closing the bug. Please reply/reopen if you disagree.
> 
> i hereby do :-)

Thanks, and apologies for my hasty action.

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to