Hi Godmar,
I hope I got your problem right, though I am still not 100% sure. Perhaps I am missing something as I don't see your issue in full context, but I will try to answer below: Am 19.08.2010 um 14:13 schrieb Godmar Back:
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.
I was in a hurry ;-)
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 ElementContentChar), nested direct constructors, CdataSections, character and predefined entity references, 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 this is expected behavior as the direct element constructor parses curly braces as defined by the grammar. The value can be used - if it is valid regarding element construction. (The one in your example is not).
You have to distinguish between Documents/Fragments that do not know about Element Constructors e.g.:
<?xml version="1.0" encoding="UTF-8" ?>
<foo>{/b/a/r}</foo>
and XQuery, e.g.:
for $x in <foo>{/b/a/r}</foo>
which evaluates the Element Constructor.
If you put the same content inside a document and query/return it no constructors will be evaluated.
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 { }.
In my opinion a node, once it has been returned (and constructed to the user's needs) should not be treated like it contained element constructors. The CDATA is not escaped as the Node is valid at the time of construction; but yes it turns erroneous if it is used for element construction in subsequent queries.
Perhaps other team members have an opinion on this too. I guess automatic escaping could be an option, on the other hand one could argue to leave this to the application programmer as valid nodes will be bloated with CDATA just in case they will possibly be used in Element construction. The escaping of curly braces can an also be done via {{ and }} [1].
Most probably the XQJ binding handled this escaping automatically,
I guess it did.
Alright, I suppose I have to consult your XQJ code because in order to avoid it I have to reimplement it.
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?
yes, seems awkward, perhaps s/o else on the list has an idea. :-/
- Godmar
[1] http://www.w3.org/TR/xquery/#id-element-constructor ~last paragraph.