Access to typed value to return () in case of type error

[avernet]

The use case provided is as follows:

(string($control-1) castable as xs:integer and $control-1 gt 0) or 
   (string($control-2) castable as xs:integer and $control-2 gt 0)

The reason is that, with types, if a part of the expression fails to find a typed value, the entire expression fails (except when short-circuiting). So here, what intuitively would be written as:

$control-1 gt 0 or $control-2 gt 0

becomes much more complicated.

I note the following ways forward:

1. Provide more support for common cases using helper functions, or possibly changing some the most unintuitive current behavior.
2. Support another expression language (JavaScript would be the prime candidate).
3. Have a more visual editor for the most common constraints (a sort of "formula editor").

Q: Would it be reasonable to change $foo or data() to resolve to an empty sequence when the typed value cannot be provided? The above scenario would work because:

(()  gt 0.0) or (1.0 gt 0.0)

returns true().

In short, the empty sequence () acts as an Option, Maybe, or null-coalescing operator in this way. Chains of arithmetic operations and comparisons result in the empty sequence. Doing this could alleviate some of the pain for more complex expressions, and take us back to what got us to support the $control and XPath types in the first place: the ability to write simpler expressions.

+1 from customer +1 from community

[ebruchez]

So this would probably be great. One question is whether at the low level, Saxon is ok with returning an empty sequence for the typed value. Two methods are involved:

• TypedNodeWrapper.atomize(): Value
• TypedNodeWrapper.getTypedValue(): SequenceIterator

They could, in theory, return an EmptySequence and an EmptyIterator. But will Saxon be ok with that?

So the next step would be to try it out and see what happens.

[ebruchez]

Also, this will be backward-incompatible in some cases at least. So this should be controlled with an XForms property. Which is not great because then we have 2 different behaviors to check/maintain. But do we have a choice?

[ebruchez]

In issue #2540, we look at the use of xs:untypedAtomic. Could this make sense here?

I would say it makes sense as far as finding what to return to the expression, but it doesn't help solving the original use case, because xs:untypedAtomic("gaga") gt 0.0 throws an error. You could write it as:

$control-1[. instance of xs:decimal] gt 0.0 or
  $control-2[. instance of xs:decimal] gt 0.0

[ebruchez]

Also, consider that what $foo returns and what a path such as instance()/foo returns could differ, because there are two different things happening:

• the code returning the typed value of a node at the XPath level
• the code assigning a value to a variable pointing to an xf:bind