If we don't implement to a standard, then there probably isn't much point in changing things.
This is a problem with SOAP: there is no standard for what goes in the envelope, and everything in SOAP outside of the envelope just seems to make it more difficult to pass around some XML.
Anyway, one standard we might consider for SOAP is to use the XML-RPC structures inside a SOAP envelope (although using XML-RPC instead is probably better...):
http://www.xmlrpc.com/specThat page has some example XML and such to give you an idea of how things look underneath.
On the other hand, there are often reasons to send well-structured XML documents and use those for integrations and inter-system messages. These are pretty well addressed in standards like OAGIS/etc.
I guess it gets back to what you're trying to do with all of this...
-David
On Mar 17, 2011, at 3:56 PM, chris snow wrote:
> (email resent as plain text)
>
>
> The current soap web service implementation uses
> org.ofbiz.service.engine.SoapSerializer to serialize/deserialize
> requests and responses.
>
> This results in an awkward xml structure, e.g.
>
> <map-Map>
> <ns2:map-Entry>
> <ns2:map-Key>
> <ns2:std-String value="partyId"/>
> </ns2:map-Key>
> <ns2:map-Value>
> <ns2:std-String value="1"/>
> </ns2:map-Value>
> </ns2:map-Entry>
> ...
>
> There are many options for tidying up the xml, one example is:
>
> <List>
> <Map>
> <Entry key-class="String" key="partyId"
> value-class="String" value="1"/>
> <Entry key-class="String" key="partyId"
> value-class="String" value="2"/>
> </Map>
> </List>
>
> Does anyone have any experience or views on how the xml should be structured?
>
> Many thanks,
>
> Chris
>>
>>
Locked
