"David" == David Carlisle <davidc(_at_)nag(_dot_)co(_dot_)uk> writes:
>>>>>> "Colin" == Colin Paul Adams
<colin(_at_)colina(_dot_)demon(_dot_)co(_dot_)uk>
>>>>>> 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
implementation).
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--