Why is there no functional xml?

[Rustom Mody]

On Tuesday, January 23, 2018 at 8:23:43 PM UTC+5:30, Peter Otten wrote:
> Rustom Mody wrote:
> > [I find the OO/imperative style of making a half-done node and then
> > [throwing
> > piece-by-piece of contents in/at it highly aggravating]
> 
> What I meant is that once you throw a bit of introspection at it much of the 
> tedium vanishes. Here's what might become of the DOM-creation as part of an 
> actual script:


«snipped named-tuple magic»

> To generalize that to handle arbitrarily nested lists and namedtuples a bit 
> more effort is needed, but I can't see where lxml.objectify could make that 
> much easier.

You really mean that??
Well sure in the programming world and even more so in the python world
“Flat is better than nested” is a maxim

But equally programmers need to satisfy requirements…

And right now I am seeing things like this
-----------------------------------------------
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <locns:blobRetrieveResponse xmlns:locns="http://example.com/">
            <REQUEST>
              <TYPE>
                AGGREGATION_ANALYSIS
              </TYPE>
              <DATASTREAM_COLLECTION>
                <DATASTREAM ID="ad907z9e-982c-4491-bc26-75bf96c0d59d">
                  <FIELDINFO FIELD="Date Stamp" FIELDTYPE="DATE" FIELDFORMAT="m/d/y" />
                  <FIELDINFO FIELD="Transaction Amount" FIELDTYPE="MONEY" LOCALE="en-US"/>
                </DATASTREAM>
              </DATASTREAM_COLLECTION>
              <COMPUTATION_COLLECTION>
                <COMPUTATION ALGORITHM="VARIANCE"
			     DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d"
			     FIELD="Transaction Amount"
			     RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" />
                <COMPUTATION ALGORITHM="MEDIAN"
			     DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d"
			     FIELD="Date Stamp"
			     RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" />
                <COMPUTATION ALGORITHM="AVERAGE"
			     DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d"
			     FIELD="Transaction Amount"
			     RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" />
              </COMPUTATION_COLLECTION>
              <DATA_COLLECTION>
                <DATA DATASTREAM="ad907c9e-982c-4491-bc26-45af96c0d59d" MODE="BLOB" TYPE="CSV">
                  «Big base64 blob»
                </DATA>
              </DATA_COLLECTION>
            </REQUEST>
        </locns:blobRetrieveResponse>
    </soap:Body>
</soap:Envelope>

-----------------------------------------------
Thats 7 levels of nesting (assuming I can count right!)


Speaking of which another followup question:


With
# Read above xml
>>> with open('soap_response.xml') as f: inp = etree.parse(f)
# namespace dict
>>> nsd = {'soap': "http://schemas.xmlsoap.org/soap/envelope/", 'locns': "http://example.com/"}

The following behavior is observed — actual responses elided in the interest of
brevity

>>> inp.xpath('//soap:Body', namespaces = nsd)
finds/reaches the node

>>> inp.xpath('//locns:blobRetrieveResponse', namespaces = nsd)
finds

>>> inp.xpath('//locns:dtCreationDate', namespaces = nsd)
does not find

>>> inp.xpath('//dtCreationDate', namespaces = nsd)
finds

>>> inp.xpath('//dtCreationDate')
also finds


Doesnt this contradict the fact that dtCreationDate is under the locns namespace??

Any explanations??