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.

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.

> 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