Comments (10)
This comes under the general rule that once you have read enough data to know that there is only one possible non-error result, you are not required to read extra data solely for the purpose of deciding whether there is an error. So reporting the error in this case is already optional.
This isn't quite the same as the 'OK'[ <a/>, 1, 'x' ]
case, which isn't an error. The case 'OK'[ 1, <a/>, 'x' ]
is an error, it's just one that you don't necessarily have to report.
We could, if we wanted, say that if the predicate value starts with a number, all non-numeric items in the value are ignored. But I don't think we should.
In the most common case for numeric predicates, the value of the predicate is going to be the same for every item in the input sequence, and in that situation you probably want to evaluate the predicate once in advance to determine all the positions that you want to select, rather than evaluating it once for every input item. So detecting the error doesn't cost you any extra. That's different from a boolean predicate such as p[child::*]
where the predicate value usually depends on the context item.
from qtspecs.
This isn't quite the same as the
'OK'[<a/>, 1, 'x']
case, which isn't an error. The case'OK'[1, <a/>, 'x']
is an error, it's just one that you don't necessarily have to report.
@michaelhkay Following this reasoning, wouldn’t it be be legal as well to raise no error for 'OK'['a', 'b']
, as the first comparison is successful?
from qtspecs.
Could we allow implementations to return true
for 'OK'[ 'a', 'b' ]
– or is this already allowed?
from qtspecs.
…and would this also apply to EBV computations, i.e., would it be legal not to report the error for boolean(('a', 'b', 'c'))
as boolean('a')
is true
?
from qtspecs.
If $seq starts with a number, E[$seq] and E[position() = $seq] will become equivalent:
I don't like that idea because it implies that if $seq
contains nodes or untypedAtomic values after the first item, they are converted to numbers under the rules of general comparisons.
'OK'['a', 'b']
In general, Errors and Optimizations says you don't need to evaluate 'b' because its value doesn't affect the final result. the only caveat is whether it comes under the exception:
There is an exception to this rule: If a processor evaluates an operand E (wholly or in part), then it is required to establish that the actual value of the operand E does not violate any constraints on its cardinality. For example, the expression $e eq 0 results in a type error if the value of $e contains two or more items.
It's not clear whether the EBV rule that computing the EBV of ('a', 'b') raises FORG0006 consitutes a "constraint on the cardinality" of the predicate expression. I don't think it does. But even if the spec allows 'b' to be ignored, I think raising the error here is the "right thing to do".
from qtspecs.
Thanks for the explanation.
I think raising the error here is the "right thing to do".
To achieve consistent behavior, we could turn it around and allow implementations to raise an error if the first item of a sequence is a node, but the second is not. Otherwise, we should possibly explain what (other than historical reasons) makes the following expressions behave differently:
$value[<a/>, 'x']
$value['x', <a/>]
from qtspecs.
At the very least, we need to clarify the spec.
from qtspecs.
These are the current rules for fn:boolean
:
- If
$input
is the empty sequence,fn:boolean
returnsfalse
. - If
$input
is a sequence whose first item is a node,fn:boolean
returnstrue
. - If
$input
is a singleton value of typexs:boolean
or a derived fromxs:boolean
,fn:boolean
returns$input
. - If
$input
is a singleton value of typexs:untypedAtomic
,xs:string
,xs:anyURI
, or a type derived fromxs:string
orxs:anyURI
,fn:boolean
returnsfalse
if the operand value has zero length; otherwise it returnstrue
. - If
$input
is a singleton value of any numeric type or a type derived from a numeric type,fn:boolean
returnsfalse
if the operand value isNaN
or is numerically equal to zero; otherwise it returnstrue
. - In all other cases,
fn:boolean
raises a type error[err:FORG0006]
.
Maybe it’s sufficient to change rule 2:
- If
$input
is a sequence of nodes,fn:boolean
returnstrue
.
The following query would then raise an error…
$value[<a/>, 'x']
Due to the rules Errors and Optimizations rules, an implementation would still be allowed to not raise the error (so the behavior would be backward-compatible), although I can imagine it would be… the right thing to do.
from qtspecs.
It doesn't feel right to me to take something that is currently permitted and well-defined by the spec and turn it into an error, with no justification other than "tidying things up". The consequence of this proposed change is that:
(a) implementations may ignore it and continue as they are, but exploiting a loophole in the spec and not behaving as users reading the spec might expect.
(b) implementations may read the entire sequence to see if it contains any non-nodes; there usually won't be any, so the query will deliver the same result but be slower
(c) a small number of applications may actually be exploiting the rules as currently written, and may break as a result of the change.
None of these consequences seems desirable. What are we trying to achieve?
from qtspecs.
My justification would have been to make the EBV rules more consistent for different input types, and to (ideally) not have it rely on implementation-specific optimizations. We have three kinds of results that sometimes seem arbitrary (false, true, error).
But I understand that the implications would generally be too far-reaching. Thanks for the explanations; I’m closing the issue.
from qtspecs.
Related Issues (20)
- Remove the `$position` argument from the `$action` function passed to folds HOT 26
- Drop the static typing feature HOT 1
- Bare brace ambiguity resolution in practice HOT 4
- Typos in fn:format-number
- The escape-solidus option should apply to xml-to-json HOT 1
- Grammar rules: redundancies HOT 1
- Nothing HOT 67
- unparsed-text-available() signature
- declare item type → item-type
- Names of private functions in XQuery library modules HOT 4
- Specs: new vs. updated features HOT 3
- map:get and array:get HOT 34
- Occurrence indicator meaning "exactly one" HOT 8
- In the EBNF, use explicit separator syntax
- Further improvements to BuiltInKeywords test needed HOT 3
- fn:round: `rounding-mode` → `mode`? HOT 1
- (type)switch: braces after `case` keyword HOT 2
- Unknown option: FORG0013 → XPTY0004 HOT 2
- XQFO: Editorial HOT 1
- Duplicate keys in map constructor HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qtspecs.