On 24.06.2014 09:32, Daniel Kinzler wrote: How about if one just keeps the maps but introduces an "order"-field into the maps values instead of taping the orders in a seperate list behind the map? It serves both views and restoring order would be easy.

How and where? Can you please give examples and link to them? I'm sorry but this is simply not true. All you need is a single additional line of code. With the proposed lists: foreach ( snak in snaks ) { ... } With the current mappings: foreach ( id in snaks-order ) { snak = snaks[id] ... } The current approach gives everybody the best from both worlds without the need to implement, test, maintain, support and bugfix two different formats. I really wonder why we are discussing this. Markus, just add similar ...-order arrays to places that miss them at the moment. Done. Best Thiemo -- Thiemo Mättig Software-Entwickler Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen Wissens frei teilhaben kann. Helfen Sie uns dabei! http://spenden.wikimedia.de/ Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

I've seen three formats proposed so far: (1) Map + order fields (current format) (2) Arrays (3) Map + sort-index inside each map item The last was proposed by Fredo; I think it got lost a bit. The idea there would be to store something like "index: 1" in the objects that are inside the map to define their order. Advantage: order information in the same subtree of the JSON (works with parsers that parallelize subtree parsing in maps). Disadvantage: objects get a new index field that is not really part of the object data but part of the context in which the object is used. Also, it still is some work to build the real list. On 24/06/14 11:27, Fredo Erxleben wrote: ... Agreed. I can see use cases for any of the formats. WDTK is less of an issue here than direct API users (bots and scripts). A script that wants to read statements will probably prefer a map; a bot that wants to change the order of properties in references would probably prefer arrays. I don't think we should argue whether one is more important than the other. From the current discussion, I would prefer the Arrays for the "internal" "main" format. Conceptually, we have a list of things, so using an Array would harmonize the JSON with the data. Daniel suggested to have a switch in the API to select format (1) optionally. I also think that something like this is needed if there would be such a change in the JSON (already for b/c with existing applications). I don't think performance is a big thing to discuss here. Any of the options we discuss will be fast enough for most applications. I would focus on the design, which needs to be fixed one way or the other (since order data for statements is missing completely). Cheers, Markus

Then we have two formats again. Only a bit less different. There must be more possibilities to solve this for everyone. There is not really a lot of possible or plausible implementations. But the real question is : is this worth the headeach ? Premature optimisation is the root of all evils. As a user, I would prefer you to focus on problems that really have an impact than to whatever question of having only one serialisation format, which is really a stractch in the big picture.