2013/6/16 Daniel Kinzler daniel.kinzler@wikimedia.de
- The data type of the property could have changed (we don't support
changing
that as far as I know but I'd always consider it). So you still had to
fetch the
property to compare its current data type with the one of the snak.
Why would I have to check that? I'm trying to interpret a value for output or such, why should I (need to) care about the property's type?
Only when *setting* a value we need to do this check, and we already need to check the datavalue's type in that case anyway.
I am in favor of always displaying existing values if possible, even if it is not valid against the current definitions (property/datatype) anymore. BUT, if the value is not valid against the definition anymore, in many situations the display of the value should come with an additional information about that. Otherwise this can be very misleading. In the JS UI we are currently not displaying those values, we only display a red message telling the user there is something wrong with the value and the user can change it into something valid or remove it.
For displaying the value in a useful way though, you don't necessarily need the PVS's Property's data type. Just having the data value, taking its data type and using a standard formatter for that data value type would be sufficient I believe. We could already do that in the JS frontend for broken values of most of our data value types, just nobody had the time to take care of it.
Also, we might add other attributes than "datatype" to properties at some point,
some might influence validation (e.g. the unit of a number). Would you
then go
ahead and add these information also to the PVS's constructor?
No, because it is only relevant for validation, that is, when the value *changes*.
Not sure you thought this through. The example I gave (unit of a number) would already be something not only relevant for validation but also for how the value should be displayed. So my question still stands. I guess there are many more possibilities of Property attributes that would not only affect validation. With your approach, we would take this flexibility. That's what I've been afraid of in the first place. An optimization that will cost us time and nerves later on.
Cheers, Daniel