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@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@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/