[Monetdb-developers] Data type of the text() nodes

Peter Boncz P.Boncz at cwi.nl
Mon Jun 4 10:17:10 CEST 2007


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 <Y.Zhang at cwi.nl>
Subject: [Monetdb-developers] Data type of the text() nodes
To: monetdb-developers at lists.sourceforge.net
Message-ID: <20070601151446.GV11079 at cwi.nl>
Content-Type: text/plain; charset=us-ascii

Hello,

I'm having a problem with the data type of text() nodes in XRPC
implementation.  

---------------------------
module function definition:
---------------------------
module namespace foo = "xrpc-test-function";

declare function foo:q2($strs as xs:string*) as node()*
{
    for $s in $strs
    return <bar>{$s}</bar>
};

-----------
test query:
-----------
import module namespace test = "xrpc-test-function"
                at "/ufs/zhang/max-nr-params/xrpc-mod.xq";

let $hello := <hello>
                <lang>en</lang>
                <lang>nl</lang>
              </hello>
let $lang := $hello/lang/text()
return execute at {"localhost"} {test:q2($lang)}
-------------------------------------------------------------

I got the error "function could not be resolved" when I run the
XRPC query above.  The reason is that all items in the sequence $lang
have the type U_A (xs:untypedAtomic), and they are marshalled in the
XRPC req. msg as, for example:
    <xrpc:atomic-value xsi:type="xs:untypedAtomic">en</xrpc:atomic-value>

At the server side, the values are unmarshalled and assigned the type
U_A again.  So far, the values are handled correctly, IMHO.

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?

The easiest solution of my problem is to just marshall an
xs:untypedAtomic as an xs:string, but if someone has better suggestions,
I would like to know.

Thanks a lot!

Regards,

Jennie



------------------------------

Message: 5
Date: Fri, 1 Jun 2007 17:27:03 +0200
From: Jens Teubner <jens.teubner at in.tum.de>
Subject: Re: [Monetdb-developers] Data type of the text() nodes
To: monetdb-developers at lists.sourceforge.net
Message-ID:
	<20070601152703.GB8539 at notekemper14.informatik.tu-muenchen.de>
Content-Type: text/plain; charset=us-ascii

On Fri, Jun 01, 2007 at 05:14:46PM +0200, Ying Zhang wrote:

> [...]
>
> 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 <jens.teubner at in.tum.de>
Subject: Re: [Monetdb-developers] [MonetDB-users] XRPC problem: too
	many	parameters
To: Ying Zhang <Y.Zhang at cwi.nl>
Cc: monetdb-developers at lists.sourceforge.net
Message-ID:
	<20070601190027.GF8539 at notekemper14.informatik.tu-muenchen.de>
Content-Type: text/plain; charset=us-ascii

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

-- 
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 <Y.Zhang at cwi.nl>
Subject: Re: [Monetdb-developers] [MonetDB-users] XRPC problem: too
	many	parameters
To: monetdb-developers at lists.sourceforge.net
Message-ID: <20070602201444.GC11079 at cwi.nl>
Content-Type: text/plain; charset=us-ascii

On Fri, Jun 01, 2007 at 09:00:27PM +0200, Jens Teubner wrote:
> 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









More information about the developers-list mailing list