Closed dlannan closed 3 years ago
This is not an issue with the library, but a characteristic of Lua Tables having named keys (that works like structs in C), instead of numerical keys (for arrays). Since the generated table will have some named keys, the iteration over them using the pairs function have an arbitrary order.
This is kind of true. But if you use ipairs you can order data. Thats exactly what most lua xml like tools do - they have an ordered index with other attached data. I was wondering why you made the keys a string, because this stops the xml from being very useful with ordering. Have moved to another xml parser for this. Not sure how this lib can be used without this simple important part of the xml structure.
Hello @dlannan, xml2lua creates a Lua table with the same exact structure of the XML. In this case, key names will be string, as it's for most of the XML files, for instance this one.
Since the lua table will be a mirror of the XML, having string keys, we can't use ipairs. That function just works for arrays (tables with numbered indexes). What you are proposing is to create an auxiliary structure to store key order. That may require some structural changes and I'm afraid I don't have the time to do that in the short term.
In fact, I don't think that may work out for this library, since its goal is to have a data table generated as a mirror of the XML file. This way, I can't store metadata as an internal key inside the data table, because current users aren't expecting this structural change on such a table. Considering that, creating an auxiliary table will require a new function to be used to iterate over the data table, that uses the auxiliary table for imposing order. It means the developer cannot use pairs or ipairs to iterate over the data table. Using a custom function for that seems odd for me.
Yeah. I understand the complexities of using normal hash tables. Its problematic when the data is structured. We usually either use a C array with ffi or use table indexed arrays (numerical indexes are consistent in lua) for our network packet data. For us, if we have a streaming xml data input and we are processing in order, then obviously there are problems ensuring the stream is correctly maintained. Its a use case that isnt suited to this library Im afraid.
I'm trying to do some svg parsing, and just stumbled on the ordering problem. @manoelcampos Maybe it would be fair to highlight in the readme that the order for xml elements is lost?
That may be great. I'm accepting Pull Requests.
When parsing an xml file to a table, the elements are put into a table and lose their order. I find this a bit puzzling because most xmls need to maintain their element ordering. Is this intended? Is there a config somewhere Im missing?