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 suspect that the vast majority of API users does not care about order. I also
like the option to access things by their ID directly, without iterating over
everything. I'd hate to give that up.
A serialization option would be a possibility (like we also have
groups/ungrouped mode) - we in fact already have such a mode, it's used for
generating XML output from the API; the XML serialization doesn't like IDs being
used as keys, it wants lists. We'd just need to expose that setting.
But then we are back to having different serialization formats for the API and
internal storage/dumps. The internal format would be much saner than it is now,
and much more similar to the API format, but it would still be different.
-- daniel
Am 24.06.2014 09:14, schrieb h:
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 see it, the mappings are causing real pain since
these simply do not represent that things are, in fact, stored in
order. The maps generate a wrong representation which, on the one
hand, may be more convenient at first glance but, on the other hand,
is confusing as soon as someone digs deeper into the API because these
"snaks-order" and "qualifiers-order" hack which got implemented when
everybody realized that we are missing order adds to complexity big
time. Personally, I would even drop the mappings completely. Yes, the
maps allow pretty fast access to values (in particular to users
inexperienced in dealing with APIs) but be sure that people using the
API will get along fine without them and Wikibase would have a single,
clean and more consistent interface. Do not fear the change. :)
I shall reiterate: STRONG SUPPORT!
_______________________________________________
Wikidata-tech mailing list
Wikidata-tech(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.