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 5617 - [FO] Summary of numeric-unary-plus
Summary: [FO] Summary of numeric-unary-plus
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-02 13:16 UTC by Oliver Hallam
Modified: 2008-10-08 16:26 UTC (History)
1 user (show)

See Also:


Attachments

Description Oliver Hallam 2008-04-02 13:16:43 UTC
Section 6.2.7 of F&O says (about numeric-unary-plus):
Semantically, this operation performs no operation.

However this behavior is inconsistent with numeric-unary-minus (and all other numeric operators).

Specifically, consider the following query:
(+xs:int) instance of xs:int

According to the specification, this evaluates to true, however would this be better casting the xs:int to an xs:integer? (i.e. should + behave the same as --?)
Comment 1 Michael Kay 2008-04-02 14:24:43 UTC
Personal response: this description of the "backing function" needs to be read in conjunction with B.2 in the XPath language spec, which makes it clear that when the argument in the op: function signature is given as 

op:numeric-unary-plus($arg as numeric) as numeric

should be read as four function signatures, one of which is

op:numeric-unary-plus($arg as xs:integer) as xs:integer

and therefore the only guarantee if the operand is an xs:int is that the result is an xs:integer. 

I agree, however, that the spec could be clarified.

I seem to recall (but cannot locate) similar comments on fn:abs() which states "If $arg is negative returns -$arg otherwise returns $arg." - its not really clear whether this allows you to return the xs:integer 3 if the supplied argument is the xs:int 3. 
Comment 2 Oliver Hallam 2008-04-02 15:21:00 UTC
Since you mention the four function signatures of numeric functions, do you have an opinion on bug #5459?
Comment 3 Michael Kay 2008-04-02 15:34:23 UTC
>Since you mention the four function signatures of numeric functions, do you
have an opinion on bug #5459?

My opinions on the static type inferencing rules in the formal semantics are best not repeated here...
Comment 4 Michael Kay 2008-04-22 17:26:03 UTC
On 22 April 2008 the WG asked the editor to propose revised text for op:unary-plus and op:unary-minus that clarifies that type promotion can take place (as is stated in the table showing the type promotion rules in the introductory section of 6.2.)

Proposed text is as follows:

For op:unary-plus (6.2.7) replace the Summary with:

Summary: Backs up the unary "+" operator and returns its operand with the value unchanged: (+ $arg). 

The returned value is equal to $arg, and is an instance of xs:integer, xs:decimal, xs:double or xs:float depending on the type of $arg.

For op:unary-minus (6.2.8) replace the Summary with:

Summary: Backs up the unary "-" operator and returns its operand with the sign reversed: (- $arg). 

The returned value is an instance of xs:integer, xs:decimal, xs:double or xs:float depending on the type of $arg.

To the originator: please close this bug if you are content with this resolution.
Comment 5 Michael Rys 2008-04-22 17:35:01 UTC
(In reply to comment #4)
> The returned value is an instance of xs:integer, xs:decimal, xs:double or
> xs:float depending on the type of $arg.

after reading the above, I think this needs to be tightened. Note that xs:int is also an instance of xs:integer. But you want to say that it is indeed only an instance of one of these four types.
Comment 6 Michael Kay 2008-04-22 18:00:36 UTC
Regarding comment #5: no, I disagree. An implementation of a function is always allowed to return a value that is an instance of a subtype of the declared return type if it chooses. That's a general rule, it's nothing specific to these two operators. (I agree there is room for debate about whether we currently say clearly what the general rule is here; but that doesn't belong as part of this bug.) 

The proposed text is being drafted as erratum E23.