enumerate XML tags (keys that will become headers) along with text (values) and write to CSV in one row (as opposed to "stacked" values with one header)

[Robert Kern]

On 2015-06-30 01:54, Denis McMahon wrote:
> On Sun, 28 Jun 2015 17:07:00 -0700, Ned Batchelder wrote:
>
>> On Sunday, June 28, 2015 at 5:02:19 PM UTC-4, Denis McMahon wrote:
>
>>> <things>
>>>    <thing>string 3</thing>
>>>    <thing>string 2</thing>
>>>    <thing>string 1</thing>
>>> </things>
>
>>> Each <thing> is just a member of the collection things, the xml does
>>> not contain sufficient information to state that <things> is an ordered
>>> collection containing a specific sequence of <thing>.
>>
>> You are right that XML does not specify that <things> is an ordered
>> collection.
>> But XML does preserve the order of the children.  There are many XML
>> schema that rely on XML's order-preserving nature.
>
> But what we *don't* know is whether the order of the umpteen identical
> tags in the XML has any significance in terms of the original data,
> although the OP seems intent on assigning some significance to that order
> without any basis for doing so.
>
> Consider the following tuple:
>
> t = (tuplemember_1, tuplemember_2, .... tuplemember_n)
>
> Can we safely assume that if the tuple is ever converted to xml, either
> now or at some future date using whatever the code implementation is
> then, that the order of the items will be preserved:
>
> <tuple>
>    <item>tuplemember_1</item>
>    <item>tuplemember_2</item>
> ....
>    <item>tuplemember_n/item>
> </tuple>

Barring bugs, yes!

> And if we're reading that xml structure at some point in the future, is
> it safe to assume that the tuple members are in the same order in the xml
> as they were in the original tuple?

Yes! Any conforming XML implementation will preserve the order.

> For sanity <item> should have an attribute specifying the sequence of the
> item in it's tuple.

While it may make you more comfortable, it's hardly a requirement for sanity.

I think you had a point in your first paragraph here, but you are obscuring it 
with FUD. The problem is not whether unadorned XML elements can be used to 
represent an ordered collection. They can and are, frequently, without any 
problem because XML elements are intrinsically ordered.

The real problem that you almost get around to articulating is that XML elements 
can *also* be used to represent unordered collections simply by ignoring the 
(preserved) order of the elements. And if you are completely blind as to the 
schema as the OP apparently is, and you are simply given a load of XML and told 
to do "something" with it, you don't know if any given collection is meant to be 
ordered or unordered. Of course, the only sensible thing to do is just preserve 
the order given to you as that is what the semantics of XML requires of you in 
the absence of a schema that says otherwise. You can always disregard the order 
later.

That said, if the data is regular enough to actually be restructured into a 
table (i.e. if <MonthDayCount> always has the same number of children, etc.), 
then it probably does represent an ordered collection. If it's variable, then 
putting it into a table structure probably doesn't make any sense regardless of 
ordering issues.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco