Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FunctionCall-049 #143

Open
michaelhkay opened this issue Jul 18, 2024 · 0 comments
Open

FunctionCall-049 #143

michaelhkay opened this issue Jul 18, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@michaelhkay
Copy link
Contributor

michaelhkay commented Jul 18, 2024

I believe this test fails under the current 4.0 coercion rules.

We have clarified the rules: see the note in §3.4.3 starting "Function coercion applies even if the supplied function matches the required type.".

We are supplying a function of type

function(element(*, lu:approximateDate)) as xs:integer
where the expected type is

function(element(*, lu:restrictedUnion)) as xs:integer

and the schema says that restrictedUnion is a subtype of approximateDate

We are calling the function with an element of type element(*, approximateDate)

The new rules say that the function is coerced to the required type even though it already matches the required type, which means that the argument to the function must be an instance of element(*, restrictedUnion) - which this is not.

I believe that the spec change is merely a clarification; a careful reading of 3.1 gives the same interpretation. So the test is wrong for 3.1 as well.

@ChristianGruen ChristianGruen added the bug Something isn't working label Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants