On Mon, Jun 04, 2007 at 10:17:10AM +0200, Peter Boncz wrote:
For this reason my proposed fix is to use the function signature type *only* if it is a subtype of the runtime type (= if it is more specific).
Dear Peter, I don't understand this "fix" for two reasons: -- Testing this direction seems odd. The dynamic type will usually be a subtype of the static type (though this is not necessarily the case, due to the difference between the `subtype' and the `promotable' relationships). -- Your "fix" only describes an `if' branch. What do you do in the `else' branch (i.e., if the static type is not a subtype of the dynamic type)?
While the above probably fixes Jennie's issue, I do think there is a problem in pathfinder with function parameter promotion. This can surface when the typeswitch() is used inside the function body. Basically, when types are promoted, the runtime representation should be forced to reflect this. AFAIK this is not done in mps -- maybe the new type annotation system (in progress) handles this? With such a system in place, the runtime type would already be xs:string and the hack I propose above would not be needed.
Right. This is a design flaw in mps. Pathfinder's algebraic backend will do these things correctly.
As an aside, I also think that there is something wrong in pathfinder with type promotion in general comparisons. Specifically, while the spec says that in case of a comparision between untyped data and a numeric, the untyped should be cast to xs:double. Pathfinder seems to apply a direct cast to the specific numeric data type (e.g. xs:integer) instead.
Example: <a t='1.1'/>/@t = 1
I think this is correctly handled in Pathfinder. See Section 4.5.2, Paragraph "Normalization" in the XQuery Formal Semantics. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Be consistent. -- `perlstyle' man page