Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #93319
| From | Robert Kern <robert.kern@gmail.com> |
|---|---|
| Subject | Re: 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) |
| Date | 2015-06-30 10:16 +0100 |
| References | (1 earlier) <mmivtd$fqa$1@dont-email.me> <mailman.150.1435477605.3674.python-list@python.org> <mmpn9p$667$1@dont-email.me> <8e7d3dd8-f7c1-4466-ae82-f25e4a252fc7@googlegroups.com> <mmspbt$88c$1@dont-email.me> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.184.1435655772.3674.python-list@python.org> (permalink) |
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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) kbtyo <ahlusar.ahluwalia@gmail.com> - 2015-06-25 11:39 -0700
Re: 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) Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-26 07:44 +0000
Re: 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) Stefan Behnel <stefan_ml@behnel.de> - 2015-06-28 09:46 +0200
Re: 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) Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-28 21:00 +0000
Re: 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) Ned Batchelder <ned@nedbatchelder.com> - 2015-06-28 17:07 -0700
Re: 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) Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-30 00:54 +0000
Re: 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 <robert.kern@gmail.com> - 2015-06-30 10:16 +0100
Re: 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) Marko Rauhamaa <marko@pacujo.net> - 2015-06-30 19:32 +0300
Re: 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 <robert.kern@gmail.com> - 2015-06-29 14:04 +0100
Re: 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) Sahlusar <sahluwalia@wynyardgroup.com> - 2015-06-29 07:52 -0700
Re: 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) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-29 21:26 -0400
Re: 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) Chris Angelico <rosuav@gmail.com> - 2015-06-30 22:40 +1000
csiph-web