Re^3: Preserve the sequence of xml elements in the generated SOAP Envelope

The reason that the elements are not coming out in the order that you think you put them it, is that you are passing a hash reference as the second argument to SOAP::Data->name(), the elements in a hash are effectively in a random order which you cannot control. If you want more control over the structure of the generated XML you will need to explicitly create every element with SOAP::Data - you can find an example in Re: SOAP Beginner ... I hate to impose.

As to the question of why the elements need to be in a particular order, in general with XML this shouldn't matter but I have seen some XML parsers get upset about this when validating against a DTD, but you generally aren't doing this in a Web Service. If you (or the owner of the web service) care at all about interoperability, you will fix the server so that it behaves in an interoperable manner rather than hacking the client to work around it's quirks.

/J\

Comment on Re^3: Preserve the sequence of xml elements in the generated SOAP Envelope Select or Download Code

Replies are listed 'Best First'.
Re^4: Preserve the sequence of xml elements in the generated SOAP Envelope by chanakya (Friar) on Apr 14, 2005 at 12:54 UTC
The question why I want the elements in a particular order is because the SOAP packet generated by the client is pretty complex. What I've given in the example in my earlier post is just a part of that. If the elements come in order, it makes life easy for debugging the required elements. Otherwise its going to be pretty tough hunting for checking a given element within the envelope. The suggestion to explicity create element with SOAP::Data holds promise. The link given will definetely help me in ordering the elements as needed. Many thanks	[reply]
Re^4: Preserve the sequence of xml elements in the generated SOAP Envelope by jhourcle (Prior) on Apr 14, 2005 at 11:11 UTC
Actually, most web services are described with WSDL these days, which for the most part used XML Schema (XSD). If a complex-type is defined as being a sequence, and not all, then they are required to be in that order. All has the limitation that each element may appear at most one time, which means that you have to use a bunch of other elements that act as arrays, and makes the XSD much more complex. More and more clients are being written by people who have no control over the server, and so, suggesting that the server be re-written is not practical. It may only have a published API that the programmer is trying to comply with, and they have no idea how it is actually implemented.	[reply]