This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4535 - [UPD] Section 2.4.4 Rename: make it optional
Summary: [UPD] Section 2.4.4 Rename: make it optional
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Working drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-04 23:34 UTC by Michael Rys
Modified: 2008-05-15 19:44 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Rys 2007-05-04 23:34:17 UTC
Do we really want to require this expression? Changing names in certain implementation context makes it hard to change. We would like to make it optional.
Comment 1 Don Chamberlin 2007-05-12 00:24:08 UTC
I think it is generally a bad idea to introduce optional features like this. It undermines our goal of interoperability.
--Don Chamberlin
Comment 2 Michael Rys 2007-05-12 01:55:37 UTC
If you rather remove it, you have my support ;-)

But as I note below, there will be implementations that cannot provide support for such functionality and thus cannot provide interoperability.
Comment 3 Martin Probst 2007-05-12 15:09:38 UTC
I think this should definitely be in the spec - changing names is need by users (see the XQuery Updates Use Cases), and implementing this operations using add/remove is very expensive, hard (or impossible) to detect by optimizers, and generally not easy in XQuery.

I also think making it an optional feature is a bad idea. It reduces the value of the standard a lot, just like with the optional axes. We should not make features that are really needed by users optional.
Comment 4 Michael Rys 2007-05-12 19:42:51 UTC
We should also not make feature madatory in the specification that cannot be implemented efficiently by certain implementations (such as for example a system that provides XML views over relational data). Because making them mandatory in the standard does not make them implemented in the real world either.

Having them optional in the standard gives those that implement it interoperability.
Comment 5 Michael Kay 2007-05-13 20:48:55 UTC
>a system that provides XML views over relational data

In the early days of the relational model, many people tried to implement relational interfaces over a non-relational data store (this was the subject of my PhD thesis back in 1975). Usually they were not able to implement the relational model with 100% fidelity, and the industry was quick to define conformance criteria (Codd's famous 12 rules) that would distinguish such systems from those that were purely relational.

I think we are now in the same situation with XQuery. Systems that have a relational data store underneath, rather than an implementation of the XDM data model, will always have difficulty implementing some constructs, and this will be particularly true of updates.

We shouldn't respond by lowering the conformance barrier: instead we should recognize that such systems, while they will never have 100% fidelity to the XML/XDM/XQuery model, nevertheless are a useful engineering approximation that offers users significant transition and coexistence benefits.

Michael Kay
Comment 6 Jonathan Robie 2007-05-29 16:02:08 UTC
I agree with Don and with Michael Kay here. XQuery is defined in terms of operations on XML, not in terms of the infinite number of possible underlying stores, and basic functionality like renaming a node is pretty much expected.

When I was at DataDirect, we carefully documented the (relatively few!) places where we were unable to conform to the specification due to limitations caused by the underlying relational databases. We never had a customer complain, because we were able to explain these limitations pretty easily, and they were few. I'm no longer at DataDirect, but in this case I would simply introduce an error saying that you can't do a rename of a node that corresponds to a table, row, or column name in an XML view. I would, however, allow renames in XML documents if it were possible in my implementation.

To me, this allows us to keep the XQuery specification clean, providing the functionality needed for XML, while still making it easy for vendors to be clear why they can't always be 100% spec compliant.
Comment 7 Jonathan Robie 2007-06-05 16:56:08 UTC
We decided to close this in today's telcon. We sympathize with the difficulties in your implementation environment, but we believe this is necessary functionality.