0
votes

I am a reasonably competent XSLT 1.0 developer.

I am experimenting in XQuery 3.0 in Oxygen.

I've got an evaluation of Oxygen, and Saxon 9.9.1.7 EE, I can force a type issue

e.g. I've defined

  <xs:element name="vhs" type="xs:string"/>

and created a query

import schema default element namespace "" at "file:/C:/Foo/Oxygen/XQuery/src/videos.xsd";  
for $x in result/videos/video
where $x/vhs>14.50
order by $x/title
return $x/title

If I run the query it fails with a sensible sort of error.

Cannot compare xs:string to xs:decimal

But can I typecheck the query without running a query? (either via API or from commandline) My doubt is that the IDE doesnt see the type error, I have to run it.

1

1 Answers

0
votes

The type system in XQuery is a hybrid between strong/strict/static typing and weak/dynamic typing. Implementations have a lot of discretion as to how much they do statically and how much dynamically. XQuery 1.0 defined strict static typing (I call it "pessimistic" static typing) as an option, but relatively few products implemented it (SQL Server is one). Under pessimistic static typing, $a/b/c is an error unless you know statically that $a is an element that always has a child named b, which always has a child named c. So a pre-condition for that is that your query is schema-aware.

Saxon implements "optimistic static typing": it only reports a type error at compile time if the construct is guaranteed to fail. For example, starts-with(12, 1) is guaranteed to fail because the arguments must be strings and you can establish statically that they aren't.

If your query were schema-aware, then $x/vhs>14.50 would be allowed if vhs is typed as xs:decimal, and disallowed if it is typed as xs:string -- provided that the type of $x is known, which depends on how you declared it. In a non-schema-aware query $x/vhs>14.50 will succeed or fail at run-time based on the actual value in the vhs element.

Taking advantage of schema-awareness can give you much better compile-time error detection. But sadly, not many people do it, because it involves extra effort at coding time, and people always believe the code they're writing will work first time.