- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Nov 2014 13:42:13 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26958 --- Comment #29 from Jonathan Robie <jonathan.robie@gmail.com> --- (In reply to Michael Kay from comment #28) > Perhaps we have a different understanding of the word preclude? > > My understanding is it means "to make impossible". The requirement is that > we shall not do anything that makes updates impossible. I think we can > achieve this by doing nothing. Your objection, going back to the original > comment in this bug entry, is that doing nothing "results in two sets of > behavior that can be distinguished only when updates are implemented". I > don't think that's a problem; the time to define the detail of how updates > work is when we design the update facility, not now. My objection is that: 1. People are creating persistent data now, and there's a big gotcha if we're going to tell them later that they created it the wrong way and it cannot be updated according to our specs. 2. There are already implementations that update JSON from an XQuery environment. Like the original update spec, implementation is happening before the specification because we are lagging on the spec. People need some guidance. 3. We know what an in-situ update is. We have a requirement to not preclude it. We have a working group decision on how to do this. > Many people (for > example, most XPath/XSLT implementors) will never implement in-situ update, > and it would be entirely wrong for specs other than the Update spec to > attempt to dictate choices that have no effect on non-Update programs. This has absolutely no effect on an implementation that never implements in-situ updates. But it still affects the non-update specs, just as XML constructors do. For XML constructors, we carefully spell out what is constructed so that updates can be done consistently. In fact, the basic question is this: should our constructors clearly state what is constructed or not? For updates, it's important to do that, because otherwise we do not know what is being updated. You seem to be taking the position that we don't need to be clear about this because it's only a gotcha if someone tries to update it. This is essential for any implementation that does in-situ updates. It has no effect on any other implementation. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 11 November 2014 13:42:15 UTC