xsl-list
[Top] [All Lists]

Re: [xsl] Removing namespaces without escaping CDATA???

2007-04-07 13:27:05

Everything inside a CDATA section is ignored by the parser.
well not everything, the only thing CDATA changes is te interpretation
of < and &.


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?

eek no! The hole point of CDATa sections (and entity definitions) are
that they are an _authoring_ convenience (for human authors) which must
have no effect on subsequent processing. It's no point offering a
simplified input sysntax if teh resulting file means something
different.

So its important that CDATA sections, entity references, the choice of "
or ' around attribute values etc are all normalised away by teh XML
parser so that any XML applications (such as XSLT) have the same
behaviour whether or not they are used. If XSLT (or other XML
applications) could "see" the CDATA section then
<foo><![CDATA[<]]></foo> would not be equivalent to <foo>&t;</foo>
which would be a bad thing.

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?

It has to be global or you have to be able to somehow annotate
individual elements in the result tree but teh need to annotate teh
result tree leads to all sorts of problems if teh result tree is not
immediately serialised by XSLT but passed to some other process, which
is why disable-output-escaping is such a problem. There is no standard
way of passing a result tree to some other process and recording places
where doe is used.

David




--~------------------------------------------------------------------
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>
--~--