This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
According to the Static Type Analysis in section 5.15 of the Formal Semantics: "The function body's type must be a subtype of the expected return type. If static typing fails, a static type error is raised." But 4.15 of the XQuery Language spec states that the rules for converting the result of a function to its declared result type, are described in 3.1.5 Function Calls, which then proceeds to list a series of atomization and promotion rules. The end result is that, by my understanding of the formal semantics, queries such as declare function local:myFunction() as xs:float { 4.0 }; do not static type check, as 4.0 is xs:decimal, which is not a subtype of xs:float. Unless I have missed something in the FS, I think the rules from 3.1.5 are missing and need to be added to the formal semantics for function declarations.
Hi Nick The XQuery WG has looked at your report and agrees to fix this issue in the next version of the document. The proposed fix is to reflect the function conversion rules for function results in the normalization rules: In 5.15: Change the normalization rule as follows: [ declare function QName ( ParamList? ) as SequenceType { Expr } ]PrologDecl == declare function QName ( [ParamList?]Param ) as SequenceType { [Expr]FunctionArgument(SequenceType)} "The function body's type must be a subtype of the expected return type." replaced with "The function body's type - after applying the function conversion rules - must be a subtype of the expected return type." With this change we mark this as FIXED. If you agree with this fix, we appreciate if you can close it. Feel free to reopen the bug if you disagree with the resolution. Although if you reopen it, the bug will most likely to be considered for an errata instead of the recommendation document.
While the proposed normalization does go some way towards the necessary function conversion I don't think it does everything needed. FunctionArgument(SequenceType) only implements 1 and 2 of the function conversion rules listed in 3.1.5. Isn't something needed to add the promotion in 3 and 4 into the normalization? While I think the change to the text covers this, I'd have thought something formal to cover type promotion would still be needed?
I think that is correct, we should add the type promotion in the static typing rule in 5.15. Something as follows: statEnv |- VarName1 of var expands to Variable1 ... statEnv |- VarNamen of var expands to Variablen statEnv + varType( Variable1 => Type1 ;...; Variablen => Typen ) |- Expr : Type ***** statEnv |- Type can be promoted to Type --------------------------------------------------------------------------------- statEnv |- function declaration declare function QName ($VarName1 as SequenceType1, ···, $VarNamen as SequenceTypen) as SequenceTyper { Expr } with signature declare function expanded-QName(Type1, ..., Typen) as Typer : Typer Where line ***** replaces statEnv |- Type <: Typer - Jerome
I think that is correct, we should add the type promotion in the static typing rule in 5.15. Something as follows: statEnv |- VarName1 of var expands to Variable1 ... statEnv |- VarNamen of var expands to Variablen statEnv + varType( Variable1 => Type1 ;...; Variablen => Typen ) |- Expr : Type ***** statEnv |- Type can be promoted to Typer --------------------------------------------------------------------------------- statEnv |- function declaration declare function QName ($VarName1 as SequenceType1, ···, $VarNamen as SequenceTypen) as SequenceTyper { Expr } with signature declare function expanded-QName(Type1, ..., Typen) as Typer : Typer Where line ***** replaces statEnv |- Type <: Typer - Jerome
Thanks. I think that should cover it, so am closing the bug. Nick