On Thu, Aug 19, 2010 at 4:14 AM, Michael Seiferle < michael.seiferle@uni-konstanz.de> wrote:
Hi Godmar,
without consulting the grammar:
Well, I had hoped I could push looking it up to you.
But http://www.w3.org/TR/xquery/#id-content says:
The part of a direct element constructor between the start tag and the end tag is called the *content* of the element constructor. This content may consist of text characters (parsed as ElementContentCharhttp://www.w3.org/TR/xquery/#doc-xquery-ElementContentChar), nested direct constructors, CdataSectionshttp://www.w3.org/TR/xquery/#doc-xquery-CDataSection, character and predefined entity referenceshttp://www.w3.org/TR/xquery/#dt-predefined-entity-reference, and expressions enclosed in curly braces.
So, { } are legal inside direct element constructors and are interpreted. This means that, oddly enough, the value returned by BaseX actually can't be used in a direct element constructor.
In my opinion, BaseX shouldn't return XML in a form that can't be used as a direct element constructor. (Note that you don't escape the CDATA, even though it contains { }.
Most probably the XQJ binding handled this escaping automatically, perhaps a
team member with more expertise in XQJ could address this.
Alright, I suppose I have to consult your XQJ code because in order to avoid it I have to reimplement it.
A quick Google search reveals: http://www.w3.org/TR/xslt#output and the cdata-section-elements Transformer property: http://download-llnw.oracle.com/javase/1.4.2/docs/api/javax/xml/transform/Tr...
which appears rather awkward since it requires that one lists all those elements whose text children should be CDATA'd. There doesn't appear to be an option to say "all," or is there?
- Godmar