This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The XQuery Updates facility candidate recommendation spec requires that expressions either return a non-empty XDM instance, or a non-empty list of pending updates, but not both or a mix thereof. This is also checked statically, not dynamically; it is not possible to write an expressions that might either return pending updates or an XDM instance. In our implementation experience, this is not useful. For example, it makes it impossible to write a query that deletes a set of nodes and returns how many have been deleted. There are many use cases that require queries to perform updates and return values at the same time. Also, in our experience it is technically not a problem to mix updates and XDM instances in one expression. We have implemented the strict W3C checking which can be optionally enabled in xDB, but we do not require it and can execute XQueries that perform both updates and create values. There are places where the distinction might be useful as an error checking tool. For example in the Transform expression (http://www.w3.org/TR/xqupdate/#id-transform), the modify clause should only contain updating statements; any value creating statements would be lost here. Requiring updating expressions here might catch user errors, but it is not clear to use if it is worth the effort.
I have also run into cases that are significantly harder to solve without the ability to return values and updates together. I recently converted a large number of Wiki pages to DocBook. Originally, I attempted to solve this by starting with an index page and creating a tree, keeping track of modes that have been visited. This seemed like the most straightforward approach - but the following query is not allowed because it hits the restriction against returning updates and values together: declare variable $prefix := "/home/jrobie/project/qpid/doc/confluence/confluence-html-export/qpid-pruned/"; declare variable $visited := <visited/>; declare function local:filetree($s as xs:string, $depth) { if ($depth < 5) then <level depth="{$depth}"> <file>{ $s }</file> { let $relname := concat($prefix, $s) let $doc := doc($relname) for $href in $doc//@href where contains($href,"htm") and not(contains($href,"http")) and (every $url in $visited/url satisfies $url != $href) return ( insert node <url>{ $href }</url> into $visited, <newcall>{ local:filetree($href, $depth+1) }</newcall> ) } </level> else () }; local:filetree("Documentation.html", 1)
The XQuery WG discussed this bug today and agreed to revisit it for XQuery Update 1.1. We noted that a solution for this problem already exists as part of the XQuery Scripting Extension 1.0.
I have also found the inability to mix updates and results a huge hinderance to creating applications using XQuery, particularly with RESTXQ [1]. Some typical problems are captured in this thread [2]. I note that BaseX has followed xDB in allowing this [3] [1] http://exquery.github.io/exquery/exquery-restxq-specification/restxq-1.0-specification.html [2] https://www.mail-archive.com/basex-talk@mailman.uni-konstanz.de/msg03624.html [3] http://docs.basex.org/wiki/Options#MIXUPDATES.
Didn't we resolve this in Hurseley? https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jul/0092.html Q2.1.2 Update primitive items, PULs as items, and Bugzilla Bug 9026, [Update 3.0] Inability to combine expressions creating pending updates & values See https://lists.w3.org/Archives/Member/w3c-xsl-query/2013Jul/0101.html Status: In progress; see https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jan/0052.html, et al, and https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Feb/0116.html, et seq See https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Mar/0010.html https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Feb/0123.html https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Feb/0126.html 1. "Minimalist" solution (2014Feb/0126.html) but complex queries will need extensive rewriting if they become updating . least editing work . probably least implementation work . keeps the complexity of different kinds of expressions & how they combine . "it's a hack" . hard to retract later 2. Full query mode (Josh has indicated Oracle doesn't want to implement) . hard to implement for some people 3. Allow more restrictive modes 4. Status quo . we have a MUST requirement, may get formal objections Need more feedback from implementors in the WG (Ghislain's Proposal) Can we make one of the modes be the proposal and get rid of the modes? It'd have to be the partial mode. re-reading Ghislain's proposal... Jonathan: it'll probably take a couple more weeks to add Ghislain's "partitioned" [Liam's term] proposal to update. Can live with it. Preferable to modes. Seems only viable approach today. DECISION: accept the partial query mode from Ghislain's proposal in https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jan/0052.html but allowing updates inside constructors for nodes, maps and arrays. ACTION A-579-19: John Snelson to incorporate Ghislain's proposal from https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Jan/0052.html into update spec, but allowing updates inside constructors for nodes, maps and arrays. ETA 9th September. Jonathan's notes from the discussion [[ . Minimalist solution - requires expressions combining updates + values to be extensively rewritten. - least editing work, easiest to write up - keeps the complexity of different kinds of expressions and how they combine 2. "Full query mode" as the only mode - Oracle won't implement 3. Allow more restrictive modes - Modes? compatibility! 4. Status quo ------------- * FLWOR Expressions If the query mode is query, only the return clause may be updating. If the query mode is full, the constraint that the nonreturn clauses in a FLWOR expression must be simple is relaxed. * Typeswitch Expressions If the query mode is query, the test expression must be simple. If the query mode is full, the constraint that the test expression must be simple is relaxed. * Conditional Expressions If the query mode is query, the test expression must be simple. If the query mode is full, the constraint that the test expression must be simple is relaxed. * Switch Expressions Constructor functions Simple map expressions Validate expressions Transform expressions (modify operand may also be updating in "query" query mode!) If the query mode is query, the test expression and the test clauses must be simple. If the query mode is full, there is no constraint. * Expressions that may be simple or updating: If the query mode is full, the following expressions are updating if one of their direct operands is updating, simple otherwise. If the query mode is query though, they are always simple and operands must be simple as well (except the modify clause of a transform expression). Filter expressions a[b] error if b is updating Simple dynamic function calls (operands may still be updating in "full" query mode!) $a(b) error if b is updating Simple static function call (operands may still be updating in "full" query mode!) a(b) error if b is updating Path expressions a/b error if b is updating Comma expressions a,b error if b is updating? a or b? Arithmetic expressions a*b error if b is updating? a or b? String concatenation expressions Comparison expressions Logical expressions Quantified expressions Node constructors #### => Take this out of the list! (ask Josh nicely ....) Unordered, ordered expressions Instance/Cast/Castable/Treat expressions Constructor functions Simple map expressions Validate expressions Transform expressions (modify operand may also be updating in "query" query mode!) #=> Do not include map constructors, array constructors in this list ]]
https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Sep/0034.html "Clarification that ACTION A-579-19 is to only apply the “query” query mode and not the “full” query mode from Ghislain’s proposal."
Resolved as described in comments #4 and #5