Dear Christian,

perhaps I misunderstand something, but I would have thought that "copy-namespaces inherit" has nothing to do with database vs. file system. After all, this setting concerns the treatment of embedded expressions and the question, whether the node obtained from an embedded expression shall or shall not inherit the namespace bindings of the node in whose constructor the embedded expression appears (the new parent, so-to-speak). In case of inherit, the constructed copy of the node referenced by $myElem should have a binding for prefix xyz:

<dummy xyz:dummy="">{$myElem}</dummy>/*

So "copy-namespaces inherit" allows me to use such a transient wrapper for adding in-scope namespaces to a given node (more precisely: create a copy of it with added in-scope namespaces). So I wonder what significance there is to any given node (e.g. the node referenced by $myElem) residing in the database or the file system?

XQuery 3.0 allows us to construct in-scope namespaces explicitly, so I should not have to resort to such a trick. However, the code I write and use must run with both, XQuery 3.0 and XQuery 1.0. So I cannot give up my trick unless I learn an alternative which is XQuey 1.0 compatible. Do you know such an alternative? How to add namespace bindings to a node which may not use these bindings in the names of its attributes and descendants?

Let me briefly report to you WHY I need to attach namespaces independently of their use in element and attribute names. I develop and daily use a large program system for transforming XSDs into various artifacts. An intermediate of crucial importance represents a schema as a tree, the nodes of which represent the elements and attributes of instance documents and carry various attributes capturing the schema-defined properties - for example the qualified name of the type definition, or the qualified name of a base type or of a group definition, or a path consisting of qualified names leading to the element declaration, To keep the tree readible, I use lexical QNames, for example:

<a:Foo z:type="b:FooType">...

Evaluating such a tree and requiring to access schema components thus identified (e.g. navigating to the type definition with the name b:FooType), I need to resolve the lexical QNames. This is possible because all required namespace bindings are added to the tree root. And now, suddenly - the programs crash because the prefixes cannot any more be resolved.

If BaseX decides to stop supporting the copy-namespaces semantics, I will have to change my programs, add the namespace bindings in the form of a map inserted into the tree and replace the builtin operation of prefix resolving against in-scope namespaces by a custom resolving against a namespaces map found in the tree. This is possible, but it is a larger action, and a critical one, as these intermediate trees are the core and pivot around which more than 30000 lines of XQuery code revolve. Before embarking on such changes, I want to be sure that they are inevitable. Strictly speaking, the new behaviour is a bug, and therefore it makes sense to inquire if the bug is deliberately accepted and "by design" made permanent.

Best regards, Hans-Juergen

Christian Grün christian.gruen@gmail.com schrieb am 16:51 Freitag, 12.September 2014:

Dear Hans-Jürgen,

my general impression is that the copy-namespaces options were not designed to go hand in hand with XML database systems. They have been keeping us busy for quite some time, and even in Version 7.7, the implementation yielded incorrect results in various cases. This is why we decided to drop them until we can offer a solution that's both correct and efficient in terms of memory consumption. Sorry for that.

I would be interested to hear more about the use case which requires you to inherit namespaces in the query result.

Christian

But from 7.8 on, copy namespaces mode "inherit" is ignored.

I would greatly appreciate if you could restore the correct behaviour, as I have code running which must be compatible with XQuery 1.0 and which needs to "add" in-scope namespaces dynamically. (And in XQuery 1.0 I see no alternative to the pattern shown below.)

Kind regards - Hans-Juergen

Example code:

declare copy-namespaces preserve, inherit;

declare function local:addNamespace($elem, $prefix, $uri) { let $qname := QName($uri, concat($prefix, ':dummy')) return <A>{ attribute {$qname} {""}, $elem }</A>/* };

let $elem := <foo/> return local:addNamespace($elem, 'z', 'http:example.com') ================================

=> BaseX 7.7:

<foo xmlns:z="http:example.com"/>

BaseX >= 7.8:

<foo/>

Dear Christian,

thank you very much for this detailed explanation, and I understand your decision to leave things as they are, for the time being, very well. I will proceed to adapt my programs to the current version.

Cordial greetings, Hans-Jürgen

Christian Grün christian.gruen@gmail.com schrieb am 10:53 Samstag, 13.September 2014:

Dear Hans-Jürgen,

perhaps I misunderstand something, but I would have thought that "copy-namespaces inherit" has nothing to do with database vs. file system.

Yes, generally, all XQuery features are completely database-agnostic. The problem is that it is much more straightforward and efficient to support the copy-namespaces options in XML main-memory fragments than it is in a database representation (and BaseX has to deal with both representations, in contrast to Saxon, Zorba, XMLPrime, MXQuery, and others). Of course, this is only my experience with BaseX (and as far as I know there is no other database-centered XQuery processor that provides bug free support of this option).

Let me briefly report to you WHY I need to attach namespaces independently of their use in element and attribute names. [...]

Thanks for presenting your scenario. I don't have an intermediate idea how to add namespace declarations without XQuery 3.0 (maybe someone else has?), so it's probably best if you stick with Version 7.7 of BaseX for now. I am sorry for that, and I can understand your point of view that the "new behavior is a bug". From our point of view, the old behavior of BaseX was just as buggy, even if it did not fail in your use cases, and hard to maintain. I would love to see this fixed in 8.0, but it's a question of free time and resources (my day is limited to 24 hours..).

Christian