Why is there no functional xml?
Rustom Mody
rustompmody at gmail.com
Tue Jan 23 22:50:45 EST 2018
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??
More information about the Python-list
mailing list