[Monetdb-developers] New serialize form of XRPC message

Ying Zhang Y.Zhang at cwi.nl
Fri Oct 27 17:25:34 CEST 2006


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




More information about the developers-list mailing list