Optional fn params vs null values

[StrayAlien]

Hi all,

Regarding the recent 1111-feel-matches-function.dmn PR. It has a number of tests in it that use a null value where an optional function parameter is specified .. like this: matches("abracadabra", "bra", null). The last parameter is defined by the spec as an optional string value.

Some of the tests are asserting passing a null value is the same as having actually not passed a value at all, like treating matches("abracadabra", "bra", null) as if it were really matches("abracadabra", "bra"). They're good tests and are specifically testing for that situation. Cool. Looking at other tests where there are optional params it looks we may have totally missed this assertion - certainly I have missed it in a number of test suites I have submitted - mea culpa.

My take on this is they are not the same and the actual return value should be null. That is, with an invocation like matches("abracadabra", "bra", null) .. it actually is passing a value to the function ... it has provided a null where there are specific domain constraints. In this case it is not a valid value, therefore, it is an invalid argument.

pattern, replacement, and flags SHALL conform to the syntax and constraints specified in clause 7.6 of XQuery
1.0 and XPath 2.0 Functions and Operators.

A null does not conform to the above. (or does it?! - opinions welcome!).

IMO, if you actually pass an argument it must match the parameter domain constraints - if not, the result should be null. And passing null is not the same as not passing an argument.

If the spec says otherwise, cool - lemme know. It would not be the first (or last!) time I am wrong, but, I feel there is a difference between passing a null value as an optional value, and not actually passing a value.

Greg.

[StrayAlien]

Hi @opatrascoiu - if we may, I'd like to go into this PR next meeting. Some stuff I don't quite get - like many of the K2-MatchesFunc-* functions are asserting a null return value. The regex is valid regex so not a syntax error. If the regex is valid and does not have a match then we'd be asserting false wouldn't we? The tests are not marked as 'error', so, not sure I understand.

[opatrascoiu]

@StrayAlien

Regarding #643 (comment).

According to the XML spec

The effect of calling the first version of this function (omitting the argument $flags) is the same as the effect of calling the second version with the $flags argument set to a zero-length string.

Also in FEEL the null value is used to define missing values or error. It felt that considering flags == null equivalent to flags == "" is more user friendly, as a default value is provided for matches() and replace() functions. Happy to discuss this.

[opatrascoiu]

@StrayAlien Regarding

#643 (comment)

These test cases were extracted from the XML test suite (see link at the top of the test files). I should have set the errorFlag to true. PR #648 addresses that. Well spotted !

[StrayAlien]

Hi @opatrascoiu , I hope you are well.

My apologies for letting the one take so long to repsond. It is not so much about the XML spec, or these specific functions. It is more about whether, as a general thing in DMN, passing null as a value for an optional argument is the same as not passing an argument. IMO it is not. If null is not in the semantic domain of the optional argument then I would think it is an error.

The act of passing a null as a argument probably suggests an error with the argument value itself. Like, if I call foo(x,y) and y is optional but, if present should be a string wth value 'a', or 'b' .... but I pass y as a value of null then I think this should be an error - it is not the same as calling foo(x) . I am passing a value outside the semantic domain for y. It is not the same as not passing an argument.

I hope that makes sense.