What is the rationale for that restriction?
well, it ain't my decision of course:-)
there is a similar constraint on codepoint-to-string that you can't give
it any non-xml code-points so can only generate xml content strings not
arbitrary unicode strings.
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0200
starts off by saying
Have the WGs considered dropping this constraint?
I got the reply
http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0088
David:
Thank you for your comment. The F&O taskforce discussed this on
12/2/2003 and decided not to make the change to allow characters that
are not legal XML characters.
so now you know:-)
I think the rationale is more or less that serialisation (and in
particular choosing a non-xml output method) is an optional feature that
conceptually follows the xslt transform which is an XML result tree aka
data model aka infoset and the result tree should be able to be stuffed
into XML pipeleines without being serialised at all and if it has null
bytes and other control codes in there some API's might be unhappy.
But as I say, don't blame me...
David
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
--~------------------------------------------------------------------
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>
--~--