Make option to force order to matter for qvars

[jimmyli97]

Currently the only restriction on qvars comes from the length restriction.

For example:

<expr>
 <apply>
  <divide/>
  <qvar>x</qvar>
  <cn>2</cn>
 </apply>
</expr>

will return the following query (if length restriction is enabled):

for $x in $m//*:apply
 [*[1]/name() = 'divide' and *[3]/name() = 'cn' and *[3][./text() = '2']]
where
 fn:count($x/*[3]/*) = 0
 and fn:count($x/*) = 3

However this does not take into account the fact that

<divide/>
<qvar>x</qvar>
<cn>2</cn>

is different from

<divide/>
<cn>2</cn>
<qvar>x</qvar>

It seems like this should be implemented as part of the qvar concept

[physikerwelt]

👍 good catch and excellent bug report. @hcohl That's how we should use github for all our development activies.

[physikerwelt]

*[1]/name() = 'divide' and *[3]/name() = 'cn' and *[3][./text() = '2']]

This fixes that

• First elemet is: <divide/>,
• 3rd element is <cn>2</cn>,
• the total length is 3
  Thus

<divide/>
<cn>2</cn>
<qvar>x</qvar>

would not match the query. You will realize that if you really create a runnable test case.

[jimmyli97]

Ohh ok my bad!

Should I make a test case for this?

[physikerwelt]

If you can;-)

[physikerwelt]

I currently think the implementatin is correct. At least the example you made would not be a problem. But if you can construct a counter example, that would be great.