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@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. _______________________________________________ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
