This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From an implementation perspective, I add a "put" update primitive to the pending update list for instances of the fn:put() function. I also find it necessary to add a "put" update primitive for the document of each node that is modified, since these documents also need to be written. I wonder whether it would be worth being explicit about the "put" event in both these ways in the XQuery Update specification?
I think adding that primitive would only be useful if it's then referenced or used in the spec, for example to define conflicts of updates. However that would be quite awkward for document updates, as the document store is currently not specified in XQuery & friends plus it's probably also quite different from implementation to implementation. When implementing the spec I actually didn't need to add a "put" primitive for modified documents as X-Hive's persistent DOM allows to modify documents without needing to re-write them.
A personal comment: my view on this is that it would be good if the concept of collections were formalised in the Data Model. With a formal model of what a collection is, it would start to make sense to formalize "put" events in the pending update list. Without it, I'm not sure that it does.
Specifying a put operation without specifying the underlying repository/collection concept might be strange, but it's sure less strange than defining an update spec that doesn't have a put operation ;-) I'm not sure if it's possible to specify collections in a meaningful way. As far as I can see all the URI-related topics in the spec are quite obscure (see the discussions on what is an illegal URI). Also I think I remember that MarkLogic implements a repository that is quite different from what other people like eXist or X-Hive implement. What would you want to specify about collections? Simply the existence of directories and file names or also overwriting, modifying existing documents, subdirectories etc?
>What would you want to specify about collections? Some uncontroversial things: a collection is an unordered finite set of documents each of which has a unique URI; a collection itself has a URI which is distinct from that of any other collection. Perhaps some more controversial things if one can get agreement: for example that collections form a hierarchy and the parent and child collections of a collection (if they exist) are accessible; that it is possible to determine for a given document whether or not it belongs to a collection and if so what is the "immediate" collection to which it belongs. Perhaps a relationship between collections and schemas/types if there is one. Some things about mutability of a collection over time (which is a problem that needs to be addressed in the data model generally). Perhaps in the fullness of time properties of collections such as their ownership and access permissions. Obviously the dual and conflicting objectives in this area are (a) to retain a high level of abstraction to permit implementation flexibility, while (b) providing as concrete a model as possible to increase the level of interoperability for applications.
(In reply to comment #4) This comment deeply impressed me. Suddenly the present situation seems almost absurd to enjoy the light of structural relationships below the document node, and to accept utter darkness above it. Suddenly it becomes conceivable to navigate across trees of collections, moving along axes and leaning on predicates which target the yet to be defined properties of collections. Web service backed XQuery implementations might perform such fell swoops of data integration on the internet scale as present implementations allow on (formally) unrelated documents and a bunch of home-defined collections. Would any present XQuery implementation suffer hardships from the emergence of a structural model where hitherto no structure at all exists? Would it not be wonderful if the W3C launched a taskforce exploring the possibilities along the lines Michael Kay sketched?
John, The Query Working Group discussed this bug report on March 20, 2007. It is the opinion of the working group that no changes are needed to the update language specification relating to this issue. The semantics of fn:put() are implementation-defined (except to say that they take place at the end of a snapshot). Adding a "put" primitive to the pending update list is a reasonable implementation strategy for this function. But since the semantics are implementation-defined, the working group does not believe that such a "put" primitive should be part of the language specification. In other words, you are free to define such a PUL primitive if you find it helpful, but the language specification does not require that all implementations must do so. If you are satisfied with this resolution to your issue, please change the status of this Buzilla item to "Closed". Thanks and best regards, --Don Chamberlin (for the Query Working Group)
Regarding the above comments that suggest extending the XQuery Data Model to include "collections": The working group feels that this is a complex issue that is beyond the scope of the first version of the XQuery Update Facility (see earlier bug report 2799 which deals with this issue.) --Don Chamberlin (for the Query Working Group)