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: ...
We gain nothing by bashing use cases, they are diverse and all equally valid.
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 _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
