[Monetdb-developers] New serialize form of XRPC message

Jan Rittinger rittinge at in.tum.de
Tue Oct 24 12:05:46 CEST 2006


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/




More information about the developers-list mailing list