#33 Allow skipping unknown XML elements

[Martin Kutter]

Though some people claim that XML Validation is the highest goal for SOAP processors, it can have very bad effects - in fact quite the opposite, i.e. accepting (formally) invalid XML in a defined way is required.

This is especially true in SOA environments: Imagine a SOAP server and a SOAP Client, both aiming to perform an upgrade, which adds a child element to a datatype.

The client usually cannot upgrade before the server is upgraded (because additional elements usually imply additional processing which will fail without the additional attribute).

The server cannot upgrade, because the client will fail fatally because of a unknown XML element.

This scenario results in an undesirable situation where SOAP Client and Server can only be upgraded simultaneously, which effectifely prevents "rolling" updates where several systems in a cluster (and in clusters in different tiers) are updated one ofter another.

One way to allow such "rolling" updates is handling unknown XML elements / attributes in a defined non-fatal way.

The probably best way to do so is just to skip them - the application above can't handle these, anyway, and returning __SKIP__ is the natural way for SOAP::WSDL's typemaps.

[Martin Kutter]

Typemaps are to be removed in 2.1, so there's a differenc concept needed.
Maybe we could implement this in the parser (which would have the charming notion of allowing to switch on "lax" behaviour on a per-object base)?

[Martin Kutter]

Has been asked for via CPAN RT: https://rt.cpan.org/Ticket/Display.html?id=42388
Increasing priority.

[Martin Kutter]

Partly implemented (for clients only) as of rev766.

[Martin Kutter]

There's no additional stuff to be done for CGI-based servers - see SOAP::WSDL::Manual::Cookbook

For mod_perl based servers you'll have to write your own handler class, though.

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 90 days (the time period specified by
the administrator of this Tracker).