Re: [Monetdb-developers] Data type of the text() nodes
Hi Jennie + Jens,
Jennie, the idea in XRPC is to put the burden of function resolution and
type promotion at the client -- server does nothing, in order to make it
easy to implement XRPC compliant web services in environments that lack any
XPath/XQuery (type analysis) support, such as simple wrapper code.
The client side (i.e. pf) already performs type promotion, otherwise the
function call would have given the resolution error at client side. So, the
only thing that needs to be done is *use* the types of the function
signature when generating the XRPC request.
..Fix around line 1000 in xrpc_client.mx..
1067 cur_kind = XTRACT_KIND(cmbn_cont_kind);
1068
1069 switch (cur_kind) {
But, Jens, there is also static vs. dynamic typing issue here. Of course,
dynamic types are often more specific than static types. An example that
excploits this is:
declare function isInt($ctx as item()* as xs:boolean {
typeswitch($ctx)
case xs:integer: return true()
default: return false()
}
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).
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.
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 stubled on this in my Friday exercise to implement selection pushdown (not
yet finished).
Peter
------------------------------
Message: 4
Date: Fri, 1 Jun 2007 17:14:46 +0200
From: Ying Zhang
[...]
But then problem happens, namely, when the server calls the function 'xquery_sig_match' (in pathfinder.mx), it concludes that xs:untypedAtomic is not a sub-type of xs:string, hence, the function signature can not be resolved.
This error does not occur if the function 'q2' is called without XRPC. So, what is the trick of pathfinder to match the signature? Is xs:untypedAtomic just treated the same as xs:string?
Hi Jennie,
the keywords to look for in the Formal Semantics are "type promotion"
and "function call". And there are the function conversion rules as
implemented in core/fs.brg:function_conversion().
Sorry for my very brief answer, but these pointers should bring you
quite far.
Jens
--
Jens Teubner
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259 Fax: +49 89 289-17263
I invented <Ctrl><Alt><Delete>, but Bill Gates made it famous.
-- David Bradley, member of the original IBM PC design team
------------------------------
Message: 6
Date: Fri, 1 Jun 2007 21:00:27 +0200
From: Jens Teubner
[...]
I forgot to say that you need to wrap "$gb-hit/Hit_gb/text()" into the fn:data() function before those values can be passed to "test:q1". This is a restriction of the current implementation of XRPC.
The values you get by selecting the "text()" child node are of the type "untypedAtomic". XRPC currently does not cast eash untypedAtomic to the expected atomic type, hence, you need to add a fn:data() to do this. I will add this cast later in XRPC's implementation.
This sounds odd. Applied to (untyped) nodes, fn:data() returns
xs:untypedAtomic. Only if a value is used in a function call, the items
are cast to the respective atomic type ("function conversion rules").
(Actually, I just saw that fn:data() is not allowed at all on untyped
nodes. Maybe this changed in the latest revisions of the specs.)
Jens
--
Jens Teubner
Technische Universitaet Muenchen, Department of Informatics
D-85748 Garching, Germany
Tel: +49 89 289-17259 Fax: +49 89 289-17263
Linus Torvalds is a lot like Bill Gates. Both are
about the same height.
-- USA Today
------------------------------
Message: 8
Date: Sat, 2 Jun 2007 22:14:44 +0200
From: Ying Zhang
On Fri, Jun 01, 2007 at 06:50:41PM +0200, Ying Zhang wrote:
[...]
I forgot to say that you need to wrap "$gb-hit/Hit_gb/text()" into the fn:data() function before those values can be passed to "test:q1". This is a restriction of the current implementation of XRPC.
The values you get by selecting the "text()" child node are of the type "untypedAtomic". XRPC currently does not cast eash untypedAtomic to the expected atomic type, hence, you need to add a fn:data() to do this. I will add this cast later in XRPC's implementation.
This sounds odd. Applied to (untyped) nodes, fn:data() returns xs:untypedAtomic. Only if a value is used in a function call, the items are cast to the respective atomic type ("function conversion rules").
(Actually, I just saw that fn:data() is not allowed at all on untyped nodes. Maybe this changed in the latest revisions of the specs.)
Jens
Hi Jens, You are right about that fn:data() does not do what I need, namely take an untypedAtomic and return an atomic value in the right type. But according to the latest revision, I think fn:data() does allow untypedAtomic as its parameter: fn:data($arg as item()*) as xs:anyAtomicType* But I need to find another way to solve this problem. Jennie
-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263
Linus Torvalds is a lot like Bill Gates. Both are about the same height. -- USA Today
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
participants (2)
-
Jens Teubner -
Peter Boncz