[Monetdb-developers] New serialize form of XRPC message

Ying Zhang Y.Zhang at cwi.nl
Fri Oct 27 18:19:57 CEST 2006


On Fri, Oct 27, 2006 at 06:04:11PM +0200, Jan Rittinger wrote:
> Hi Jennie,
> 
> you already have a dynamic name in your hands -- the one used for the 
> result tag in the normal xml mode. Please do *not* add something to the 
> XqueryCtx. Either misuse the result tag (see 'dflt_ws->restag' -- it is 
> not used in this mode) or add another field and transport it via the 
> init function to your callbacks.
> If you choose the former variant I would ask you to rename 'res_tag' 
> into 'res_name' as this name does not contradict its use.

thanks.  dflt_ws indeed looks like a beter place

Jennie

> 
> Jan
> 
> On 10/27/2006 05:25 PM, Ying Zhang wrote with possible deletions:
> >Hi Jan,
> >
> >The serialization of a sequence item in the SOAP mode and in the typed
> >mode differs only in the prefix ("xrpc" v.s. "result").  If it is
> >possible to assign the value of this prefix dynamicly, I would be able
> >to reuse "typed_xml_seqItemStart" and "typed_xml_seqItemEnd" for
> >serializing soap messages.  It seems not necessary to me to implement
> >two new functions for SOAP mode, only because the prefix is different.
> >
> >A way to implement this might adding a field, call it "prefix" or
> >"typedPrefix", in the struct "XqueryCtx".  The value of "prefix"
> >can be then assigned in "createWsContext".
> >
> >What do you think?
> >
> >Jennie
> >
> >On Tue, Oct 24, 2006 at 12:05:46PM +0200, Jan Rittinger wrote:
> >>Hi Jennie,
> >>
> >>Your output looks pretty good. I would reuse as much as possible from 
> >>the xml-typed mode. If you however have conflicts then I'd introduce new 
> >>callbacks.
> >>
> >>In your case it seems sensible to introduce all the namespace 
> >>declarations in some xrpc_serializeStart event that also prints the 
> >>whole envelope tag. A xrpc_serializeStop event may then close this 
> >>element. In addition you would need a new xrpc_seqStart and xrpc_seqEnd 
> >>callback that uses a user-given sequence name and does not generate the 
> >>namespace declarations.
> >>
> >>As you can see I proposed to introduce two new callbacks that have to be 
> >>placed before/after the loop over the different iterations -- That 
> >>change would be fine with me. It however requires to introduce dummy 
> >>routines that have to be called for all modes except xrpc (the 
> >>serializeFunStruct and its instances have to be modified -- see 
> >>serialize*.mx and modules/...).
> >>
> >>What do the other think?
> >>
> >>Jan
> >>
> >>On 10/23/2006 05:32 PM, Ying Zhang wrote with possible deletions:
> >>>Hello Jan,
> >>>
> >>>With this e-mail, I would like to ask for your advice how I can
> >>>reuse/adjust the current serialization code of the "typed" mode to
> >>>support serializing the new XRPC response message.
> >>>
> >>>Maybe you have seen in our (Peter and I) XRPC paper for PLAN-X that we
> >>>have defined an XML schema for the XRPC request and response messages.
> >>>The schema definition file is avaible here:
> >>>            http://monetdb.cwi.nl/XQuery/XRPC.xsd 
> >>>
> >>>An XRPC response message now looks like this:
> >>>
> >>>    <?xml version="1.0" encoding="utf-8"?>
> >>>    <env:Envelope
> >>>      xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>      xmlns:env="http://www.w3.org/2003/05/soap-envelope"
> >>>      xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope 
> >>>      http://www.w3.org/2003/05/soap-envelope"
> >>>      xmlns:xrpc="http://monetdb.cwi.nl/XQuery"
> >>>      xsi:schemaLocation="http://monetdb.cwi.nl/XQuery 
> >>>      http://monetdb.cwi.nl/XQuery/XRPC.xsd">
> >>>      <env:Body>
> >>>        <xrpc:response xrpc:module="xrpcmodule" xrpc:method="test">
> >>>
> >>>          <xrpc:sequence> 
> >>>            <xrpc:document><a/></xrpc:document>
> >>>            <xrpc:element><a/></xrpc:element>
> >>>          </xrpc:sequence> 
> >>>          <xrpc:sequence> 
> >>>            <xrpc:attribute x="y"/>
> >>>            <xrpc:text>z</xrpc:text>
> >>>          </xrpc:sequence> 
> >>>          <xrpc:sequence> 
> >>>            <xrpc:processing-instruction>z</xrpc:processing-instruction>
> >>>            <xrpc:comment><!-- some comments --></xrpc:comment>
> >>>            <xrpc:atomic-value 
> >>>            xsi:type="xs:integer">1</xrpc:atomic-value>
> >>>            <xrpc:atomic-value 
> >>>            xsi:type="xs:decimal">42.100000</xrpc:atomic-value>
> >>>            <xrpc:atomic-value 
> >>>            xsi:type="xs:string">bla</xrpc:atomic-value>
> >>>          </xrpc:sequence>
> >>>
> >>>        </xrpc:response>
> >>>      </env:Body>
> >>>    </env:Envelope>
> >>>
> >>>As you can see, the new form of XRPC response message is quite different
> >>>than the current form of the XRPC messages, but it is very similar to
> >>>the way the result of an xquery is serialized in the "typed" mode.
> >>>During the making of the new schema, we have actually consulted the
> >>>output of the "typed" mode to use the same type names, so that we can
> >>>reuse as much as possbile the code of the "typed" mode.
> >>>
> >>>The "xrpc:sequence" part is very similar to the "result:sequence" part
> >>>of the typed mode.  In serialize_dflt.mx, the seriializeFunStruct-s of
> >>>"xml typed" and "xml soap" only differ in the following:
> >>>
> >>>struct serializeFunStruct               struct serializeFunStruct 
> >>>typed_xmlSerializeFun = {               typed_xmlSerializeFun = {
> >>>    "xml typed",                            "soap xml",
> >>>
> >>>    typed_xml_seqStart,                     xml_seqStart,
> >>>    null_complete_seqStart,                 xml_complete_seqStart,
> >>>    typed_xml_seqEnd,                       xml_seqEnd,
> >>>    typed_xml_seqItemStart,                 soap_xml_seqItemStart,
> >>>    typed_xml_seqItemEnd,                   soap_xml_seqItemEnd,
> >>>    null_seqItemSeparator                   soap_xml_seqItemSeparator
> >>>};                                      };
> >>>
> >>>If we make two changes in the typed_* functions, all xml_* and soap_*
> >>>functions in "soap xml" can by replaced by the typed_* functions to
> >>>procude the new XRPC response messages.  With these changes, we can even
> >>>get rid of the "soap" mode, and just use the "typed" mode to serialize
> >>>XRPC response messages.
> >>>
> >>>The changes I would need are the following:
> >>>
> >>>(i) instead of using the static prefix "result", use a dynamically
> >>>specified prefix, so that i.s.o. "result:sequence", "xrpc:sequence" can
> >>>be printed for XRPC response messages.  Can we store the prefix in the
> >>>existing parameter XqueryCtx* ctx? Or do we need to add a new parameter
> >>>to the typed_* functions?
> >>>
> >>>This change is not _strictly_ necessary, since I can also use the prefix
> >>>"result" in the XRPC response messages, but using dynamically specified
> >>>prefixes looks nicer/cleaner to me.
> >>>
> >>>(ii) for XRPC response messages, I'd prefer to not have the namespace
> >>>definitions of "result" (or "xrpc"), "xs" and "xsi" in
> >>><result:sequence>, because each XRPC response message can contain a
> >>>(large) number of sequences.  With the NS definitions of "result", "xs"
> >>>and "xsi" included in every sequence tag is obviously wasting of
> >>>bandwidth.  Do you have an idea how this change can be implemented
> >>>nicely?
> >>>
> >>>
> >>>I hope I have made my problems and ideas clear.  Please ask me if it is
> >>>not so.
> >>>
> >>>Thanks in advance!
> >>>
> >>>
> >>>Regards,
> >>>
> >>>Jennie
> >>>
> >>-- 
> >>Jan Rittinger
> >>Database Systems
> >>Technische Universit?t M?nchen (Germany)
> >>http://www-db.in.tum.de/~rittinge/
> >>
> >>-------------------------------------------------------------------------
> >>Using Tomcat but need to do more? Need to support web services, security?
> >>Get stuff done quickly with pre-integrated technology to make your job 
> >>easier
> >>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >>_______________________________________________
> >>Monetdb-developers mailing list
> >>Monetdb-developers at lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/monetdb-developers
> >
> >-------------------------------------------------------------------------
> >Using Tomcat but need to do more? Need to support web services, security?
> >Get stuff done quickly with pre-integrated technology to make your job 
> >easier
> >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >_______________________________________________
> >Monetdb-developers mailing list
> >Monetdb-developers at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/monetdb-developers
> >
> 
> -- 
> Jan Rittinger
> Database Systems
> Technische Universit?t M?nchen (Germany)
> http://www-db.in.tum.de/~rittinge/




More information about the developers-list mailing list