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