So for instance, given this SOAP request a typical Zato service can just freely access the elements without any particular effort.
The trick is, Zato uses lxml as its underlying XML parsing library and what can strike one as a smack of pure brilliancy, lxml.objectify's default mode of operation is to assume any child elements are in the same namespace their parent is.
It may seem nothing big at first but this is exactly the feature that makes working with SOAP in lxml as elegant (pythonic) as it can possibly get.
90% of time one will be working in the same namespace so why remember about it at all?
Yes, namespaces come in handy and yes, there can be multiple namespaces in one document but given that the prevailing majority of SOAP processing is to do with the single one namespace this particular document's business payload is in, why not forget about the whole thing?
Not having to deal with it at all was an excellent idea on lxml's part that greatly reduces time spent on development and improves the resulting code's readability, hence lowering the total maintenance costs.
The code above looks like accessing regular Python objects, or perhaps JSON. There is nothing really XML-specific to it.
This is what Zato actually does - it finds the first child in soapenv:Body, turns it into a Python object and makes it available to a service in self.request.input.
If you're coming to Zato or Python with background in other programming languages, this single feature will make SOAP processing a new experience for you.
What if you really need to access multiple namespaces? This, of course, is possible, as in the example below (which is a standalone program, not a Zato service, but the same thing can be done in Zato too).