[Xml-compile] error: element `SLAObject' not processed at {http://brixworks02.example.com:8080/API/SOAP/Utils/}getSLASResponse/sla_list

[Joshua Keroes]

Thank you for the educated review - I'll pass your statements back to EXFO
ASAP.

I am, in fact, using XML::Compile - and it's working - but I'm doing
horrible things to make that succeed. We had a lot of money on the line,
dozens of eyeballs, and needed to make things work with three whole days.
XML::Compile (and Dancer and Moose) made that possible. Today, I was able
to get a fully functioning WSDL-REST middleware online.

Working around the broken XML required pulling it from the
XML::Compile::SOAP::Trace object (so glad that was made available), fixing
it, manually handling the errors, then serializing it with
Dancer::Plugin::REST, and sending it along.

As long as I've already bought my handbasket and punched my ticket, I'm
wondering is there's a place to insert an XSLT in XML::Compile's processing
chain? If I could get my hands on the XML response fresh from the SOAP
server, correct it, then XML::Compile would be able to proceed correctly.
On the scale of evil, that seems more like level three of Hell than level
seven.

What do you think?

All apologies to Dante,
Joshua


On Tue, Jan 24, 2012 at 2:03 PM, Mark Overmeer <mark at overmeer.net> wrote:

> * Joshua Keroes (joshua at keroes.com) [120124 03:42]:
> > All of the WS actions are resulting in the same "element ... not
> > processed" error.
> >
> > The only thing I can see is that the SLAObject type in the response
> > may not be getting placed in the correct namespace.
>
> There are many things wrong and weird with the XML.
>
> To start with
>   http://brixworks02.example.com:8080/API/SOAP/Utils/"
> it is forbidden to use a namespace which is not a domain you own
> yourself.  And why should one use a portnumber in here?  A namespace
> is not the address of a server!!!!  If anything, it should be the
> location of the schema/wsdl files.
>
> Then
>   <pending xsi:type=3D"xsd:int">0</pending>
>  <active xsi:type=3D"xsd:int">0</active>
>   <shared xsi:type=3D"xsd:int">0</shared>
> The elements are of type xsd:boolean
>  http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/#built-in-datatypes
> With xsi:type you can replace an element which extend the indicated type.
> Well, an int is not an extension of a boolean.  And why is it an int here?
>
> This is bad:
> >  <account_id xsi:nil=3D"true"/>
> >  <description xsi:nil=3D"true"/>
> You can only use this trick when the element has a nillable=3D"true"
> attribute.  I have seen this mistake the other way around, where
> people treat a nillable attribute as were it optional. I even made
> an work-around with the interpret_nillable_as_optional attribute.
> This schema, however, would need a "nillable_means_missing", or
> something like that.
>
> And yes, you're right: this is a bug as well:
> > <SLAObject xmlns=3D"" xsi:type=3D"namesp1:SLAObject">
> The schema has elementFormDefault=3D"qualified"
>
> Conclusion: the schema component in this wsdl is horribly broken. In
> many respects. You cannot use XML::Compile(::SOAP) in this case.
> --
> Sorry,
>               MarkOv
>
> ------------------------------------------------------------------------
>       Mark Overmeer MSc                                MARKOV Solutions
>       Mark at Overmeer.net                          solutions at overmeer.net
> http://Mark.Overmeer.net                   http://solutions.overmeer.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/xml-compile/attachments/20120126/95=
2536a9/attachment.htm