Hi Mike,
I beg to differ with you about CDATA section usefulness.
If the text in XML contains a lot of "<" or "&" characters - as
program code often does - the XML element can be defined as a CDATA
section. (ref: http://www.w3schools.com/xml/xml_cdata.asp).
Everything inside a CDATA section is ignored by the parser.
Therefore, I think CDATA is pretty useful facility.
If transformer and serializer should not be tightly coupled with this
kind of syntax, <xsl:element name="qname" cdata-section="yes | no" ..
Can't we incorporate CDATA in XPath data model? i.e. would it be
useful, if CDATA sections could be first class nodes, as text nodes or
element nodes?
Also, specifying cdata-section-elements here, <xsl:output
cdata-section-elements="qnames" /> seem to have a shortcoming, that
it's too global (as I said earlier). Do you agree to this point?
If my suggestions make sense, perhaps this could become one of the
requirement for XSLT 2.x/3.0 or XPath 2.x/3.0.
On 4/7/07, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
> The declaration, <xsl:output cdata-section-elements="qnames"
> /> seems to have a shortcoming. It's not generic; in a sense
> that it is global (all elements anywhere in the tree will be
> affected by it).
>
> Any comments please..
>
I think the experience with disable-output-escaping shows that any facility
that requires out-of-band communication between the transformer and the
serializer is architecturally very bad news.
Mind you, I've never found cdata-section-elements very useful. It only
serves to encourage people in the mistaken belief that CDATA section
boundaries are information-bearing.
Michael Kay
http://www.saxonica.com/
--
Regards,
Mukul Gandhi
--~------------------------------------------------------------------
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>
--~--