[Xml-compile] Callback returned element must use type not name

[Robin V.]

Hi Mark,

I would have preferred to give an answer earlier, but I didn't find
the time to test this new version before.

I've just checked the 2.14 version and it is now correct and coherent
(the behavior of x:c:s is the same between explain() and the structure
the callback must return - and in fact, it's what I expected it to be
in the first place).

Now, this form:
        {
        CheckStatusAnswerInfo => [...],
        Answer => [..],
        AnswerExtension => {}
        }

is much more natural than the previous one:

       {
       ProducerResponseEndpointStructure => [...],
       CheckStatusResponseBodyStructure => [...],
       ExtensionsStructure => {}
       }

Those complex wsdls/schemas are a real nest of twisted/strange cases.
I wonder if anybody on the internet already thought to collect them
and use them for a regression test suite :).

Thanks again for the support!
Robin

PS: I switched back my experiments to java for web/jsf tests, I'll try
to make a test case with jax-ws returning a soap fault to check what
is the expected structure of the soap fault with my WSDL (a point that
was left unverified)

On Mon, May 17, 2010 at 1:19 PM, Mark Overmeer <solutions at overmeer.net> wrote:
>
> I have just released XML::Compile::SOAP 2.14.  The problem is the
> other way around: explain() is right, but your code isn't.
>
> In most SOAP-RPC/type definitions in WSDLs, I saw the same name for
> the part as for the data structure. So, I did not see that the code
> was actually wrongly taking the type name where it should have been
> the part name. That must be corrected, for instance because there
> can be multiple parts using the same type.
>
> Sorry for the inconvenience of this interface breaking change.
>
> * Robin V. (robinsp at gmail.com) [100426 20:05]:
>> I upgraded xml::compile and xml::comile::soap and checked the (maybe
>> experimental?) WSDL->explain method.
>> For a given callback, this "explain" method prints that the returned
>> element should look like this:
>>
>> sub handle_CheckStatus($)
>>    # Part type {http://www.siri.org.uk/siri}ProducerResponseEndpointStructure
>>    my $CheckStatusAnswerInfo = {};
>>
>> But in fact, I must use a hash like this for the callback to return data:
>> ProducerResponseEndpointStructure => XXX
>
>> There seems to be a mixup between type and name of the parameters.
> --
> Regards,
>               MarkOv
>
> ------------------------------------------------------------------------
>       Mark Overmeer MSc                                MARKOV Solutions
>       Mark at Overmeer.net                          solutions at overmeer.net
> http://Mark.Overmeer.net                   http://solutions.overmeer.net
>
>