Minor errors in QT4 tests

[johnlumley]

I'm working though most of the QT4 tests and coming across minor errors in some of them (apart from dependency errors as a separate issue). Here I'll list them as I come across them. Please correct me if I'm wrong:

DynamicFunctionCall-R-081 is:

let $f := function($in as recod(x as xs:positiveInteger)) as xs:negativeInteger {
         -$in?x
         }
         return $f(map{'x':-5})

where record has been mistyped.

map-empty-06 and array-empty-06 The test expression:

for $i in 0 to 1
let $m := map:merge((1 to $i) ! map { .: . })
return map:empty($m)

doesn't appear to me to be a valid ForExpr as it seems to be something like SimpleForBinding SimpleLetClause SimpleReturnClause, which the grammar doesn't permit.

[johnlumley]

A similar issue arises for compare-boolean-05:

let $v := current-date() ! year-from-date(.) ! (. > 1000, . < 1000)
for $a in $v
for $b in $v
return compare($a, $b)

For each of these three I suggest a missing return after the first SimpleXBinding is needed.

[ChristianGruen]

@michaelhkay Maybe it would make sense to align XPath 4 with XQuery in this respect? What's the rationale for the restrictive grammar rules?

[johnlumley]

@ChristianGruen I hadn't realised how divergent for and let were between XQuery and XPath, even without the windowing feature. As you'll have gathered I'm working strictly on the XPath grammar at the moment. The tools I'm working on (generating an iXML grammar from the XML grammar definition of XPath and then running parses across all the test suite test cases) should be applicable to XQuery, to check there, if that would be helpful.

[michaelhkay]

@ChristianGruen The primary rationale for the restrictions was to avoid XPath engines needing to implement the infrastructure for "tuples of variable bindings", which is a heavy bit of technology needed only for weird edge cases - nearly all practical use cases can be reduced to nested loops iterating over sequences of items. In fact, I think you can probably achieve that objective by including everything except order by and group by (though I would also leave out windowing).

At the time group-by was introduced I argued strongly for it being defined over sequences of items rather than sequences of tuples, because that was enough for all the known use cases, but I was in a minority of one. And then windowing came along, and hey, it was defined over sequences of items.

In practice we've been drip-feeding parts of FLWOR expressions into XPath one little feature at a time.

[johnlumley]

In QT4/misc test Keywords-map-of-pairs-1

let $x := map:of-pairs(input := map{'key':'n','value':false()},map{'key':'y','value':true()}, 
                                   combine := fn:op(','))
     return fn:deep-equal($x, 
                      map:of-pairs(map{'key':'n','value':false()},map{'key':'y','value':true()}, 
           fn:op(','))) 
          and $x instance of map(*)

the first argument (input) of both map:of-pairs() calls need brackets around the sequence of two maps to correspond both with the function signature and in the first case the grammar for an ArgumentListwith KeywordArguments

[johnlumley]

DynamicFunctionCall-R-086:

let $f := function($in as record(x as enum("a", "b", "c", "d")) as 
            enum("A", "B", "C") {
               upper-case($in?x)
         }
         return $f(map{'x':"d"})

is missing a closing bracket between the function arguments and its as enum("A"... type. This corresponds with the correct syntax in R-085 and would have generated a 'wrong-error' rather than failure during testing.

[johnlumley]

Another minor one: DynamicFunctionCall-140 has a semicolon separator rather than a returnkeyword at the ReturnClauseposition.

[ChristianGruen]

Another minor one: DynamicFunctionCall-140 has a semicolon separator rather than a returnkeyword at the ReturnClauseposition.

@johnlumley You can check out the latest version, it has recently been fixed (https://github.com/qt4cg/qt4tests/blame/master/prod/DynamicFunctionCall.xml#L618).

[ChristianGruen]

@johnlumley Now that the XPath grammar was relaxed, do you think that all your observations in this issues have been considered?