> Question 2: Wouldn't it be more convenient to store lists of things in all
> cases, and have the "map" version just as an optional API switch for users
> who don't care about order (it could remain the default)? This would help to
> retrieve order information more easily.
Strong support! As I se
Hearing these arguments while we are in the process of consolidating the
internal and external representations makes me feel like we actually do want
different serializations: one that contains all the info, including order, and
one that is convenient to use for the most common use cases.
I suspec
I support dropping maps (at least in the default format) in favor of
arrays where things actually are sorted lists.
On Tue, Jun 24, 2014 at 9:32 AM, Daniel Kinzler
wrote:
> Hearing these arguments while we are in the process of consolidating the
> internal and external representations makes me fe
On 24.06.2014 09:32, Daniel Kinzler wrote:
Hearing these arguments while we are in the process of consolidating the
internal and external representations makes me feel like we actually do want
different serializations: one that contains all the info, including order, and
one that is convenient to
> the mappings are causing real pain
How and where? Can you please give examples and link to them?
> these "snaks-order" and "qualifiers-order" hack [...] adds to
> complexity big time.
I'm sorry but this is simply not true. All you need is a single additional
line of code.
With the proposed li
On 24.06.2014 11:03, Thiemo Mättig wrote:
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 c
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
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 somethin
Then we have two formats again. Only a bit less different. There must be
more possibilities to solve this for everyone.
> Is there a way we can fix the order implicitly?
> Or can we assure that the map is always written into Json in the correct
> order?
> Maybe use a combination of Property and in
