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

Re: [xsl] Disable output-escaping

Subject: Re: [xsl] Disable output-escaping
From: Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>
Date: 27 Jan 2005 20:10:15 +0000

>>>>> "David" == David Carlisle <davidc@xxxxxxxxx> writes:

    >>>>>> "Colin" == Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>
    >>>>>> writes:

    Colin> or equivalently, add a use-character-maps attribute to
    Colin> xsl:value and xsl:text.

    David>    Well, not, it's no quite equivalent, as you can't
    David> defining a mapping for ASCII NUL to ASCII NUL (for
    David> instance) using character maps, as it won't pass the XML
    David> parser.

    David> well you can't use d-o-e with nulls either as you can't get
    David> them into the data model at all, so the above, while true
    David> doesn't really affect equivalence.

I was thinking of fn:codepoints-to-string, but checking up, it says it
has to be legal characters, so u are tight - it is irrelevant.

    David> But I'm not sure how you would see a u-c-m attribute on
    David> xsl:value and xsl:text working. a character map already
    David> applies to all text in the result tree including any text
    David> generated by these. The whole reason why character maps are
    David> less intrusive than d-o-e is that they apply to the whole
    David> tree so don't need magic properties on individual
    David> characters.

But they do - as mapped characters are not subject to escaping, and so
d-o-e is in effect for them individually.

I was just saying that making u-c-m  on an xsl:value or xsl:text
like that would be equivalent to d-o-e (and therefore have the same

    David> Or perhaps you mean that the u-c-m would not be applied at
    David> serialisation time but actually affect the string value of
    David> the node generated

No, I didn't mean that.
Colin Paul Adams
Preston Lancashire

Current Thread