[Monetdb-developers] New serialize form of XRPC message

Jan Rittinger rittinge at in.tum.de
Fri Oct 27 18:04:11 CEST 2006


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.

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