Has there been any progress on this issue?
Independent of whether we are using the XQJ binding to access BaseX, it is nearly useless to us if it can't handle XML namespaces on operations as simple as replacing a node.
Would we be running into this issue if we didn't use XQJ?
Please give us some indication on how mature you think BaseX's support for XML namespaces is.
Thanks.
- Godmar
On Sun, Jul 11, 2010 at 5:38 PM, Christian Grün christian.gruen@gmail.comwrote:
True; I've passed this on to our expert on XQuery Update.
Thanks, Christian ___________________________
On Sun, Jul 11, 2010 at 11:34 PM, Godmar Back godmar@gmail.com wrote:
To follow up on my previous email, we observe the following. We run a query: declare namespace libx='http://libx.org/xml/libx2'; declare namespace atom='http://www.w3.org/2005/Atom'; declare variable $entry as xs:anyAtomicType external; declare variable $id as xs:string external; declare variable $feed as xs:anyAtomicType :=
doc('libx2_feed')/atom:feed;
delete node $feed/atom:entry[atom:id=$id], (: INVESTIGATE: this results in wrong xmlns entries :) insert node $entry into $feed whereby we bind 'entry' to a DOM node using the org.w3c. Implementation. When we print the about-to-be-inserted entry from Java code prior to insertion, we see:
<?xml version="1.0" encoding="UTF-8"?><entry
xmlns="http://www.w3.org/2005/Atom" xmlns:libx="
http://libx.org/xml/libx2%22%3E
<id>3</id> (rest omitted) If we run a database dump via the org.basex.BaseX program (query: doc('libx2_feed')) right after the update, we see this: <entry xmlns="" xmlns="http://www.w3.org/2005/Atom" xmlns:libx="http://libx.org/xml/libx2"> <id>3</id>
<title> (rest omitted) Other than the spurious 'xmlns=""', the rest looks ok. It seems to me that BaseX should never allow two default namespace
prefixes
for any element.
- Godmar