[Bug 14662] New: 2.3.2 Updating Annotation Assertion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 14662] New: 2.3.2 Updating Annotation Assertion

Bugzilla from bugzilla@jessica.w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14662

           Summary: 2.3.2 Updating Annotation Assertion
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Update 3.0
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]
         QAContact: [hidden email]


<quote>
The %fn:updating annotation can also be used as an assertion on a FunctionTest
to change the kind of function item matched by the test. If the %fn:updating
assertion is specified on a FunctionTest, then it matches both simple function
items and updating function items. Otherwise the FunctionTest only matches
simple function items.
</quote>

I want to be able to test for all three of the following:

* A non-updating function - perhaps %fn:non-updating?
* An updating function - perhaps %fn:updating?
* Any function, whether or not it is updating. You don't need updating
assertions for this.

The current syntax doesn't seem to meet that criteria.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 14662] 2.3.2 Updating Annotation Assertion

Bugzilla from bugzilla@jessica.w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14662

--- Comment #1 from John Snelson <[hidden email]> 2011-11-15 15:02:30 UTC ---
I need to use cases for why you want to match only an updating function. After
all, a simple function is just an updating function that happens to return an
empty pending update list.

I guess what I'm saying is that the only interesting case is "never returns a
pending update list". If you disagree, I'd like to see motivational use cases
so I can understand better.

--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 14662] [UPD 3.0] 2.3.2 Updating Annotation Assertion

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14662

--- Comment #2 from Jonathan Robie <[hidden email]> 2012-01-09 21:36:16 UTC ---
(In reply to comment #1)
> I need to use cases for why you want to match only an updating function. After
> all, a simple function is just an updating function that happens to return an
> empty pending update list.

Not according to our own definitions:

[Definition: A simple expression is any XQuery expression that is not an
updating expression.]

That definition is used in both XQuery Update Facility 1.0 and 3.0.

I'm not sure we need use cases to say that %fn:updating should not match a
function that is not an updating function.

Especially since we use the annotation %fn:updating to say that a function is
an updating function. Most users would expect the annotation assertion
%fn:updating to match those functions that have the assertion %fn:updating.

> I guess what I'm saying is that the only interesting case is "never returns a
> pending update list". If you disagree, I'd like to see motivational use cases
> so I can understand better.

If the only interesting case is "never returns a pending update list", then
perhaps we only need the annotation assertion %fn:non-updating. That name is a
lot less surprising to me.

But I can imagine scenarios in which updating functions would be handled
differently, e.g. they might require some form of authentication before they
are allowed, or they may fail gracefully. We currently define functions like
fn:doc-available() so users can write code to handle the case in which fn:doc()
will fail - similar kinds of code might be useful if passing an updating
function as a parameter to another function would fail.

--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 14662] [UPD 3.0] 2.3.2 Updating Annotation Assertion

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14662

--- Comment #3 from Jonathan Robie <[hidden email]> ---
In today's meeting, we agreed to allow these three possibilities:

%updating("allowed")
%updating("prohibited")
%updating("required")

e.g.

declare function local:foo($x as %updating("allowed") function())
{

};

declare function local:foo($x as %updating("prohibited") function())
{

};

%updating("allowed") means the same thing as the current %updating function
assertion.  (Note that we need to change the term to "function assertion" in
the update spec.)

The meaning of "prohibited" and "required" is obvious, matching only if the
function is non-updating or updating respectively.

--
You are receiving this mail because:
You are the QA Contact for the bug.

Reply | Threaded
Open this post in threaded view
|

[Bug 14662] [UPD 3.0] 2.3.2 Updating Annotation Assertion

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14662

Jonathan Robie <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--
You are receiving this mail because:
You are the QA Contact for the bug.