The use case currently is the formatterUrl property info. We cannot get the formatter url within the value formatters because it depends on the property id. Therefore, the decision which formatter/which formatting options to use must be made on the snak level, in particular `PropertyValueSnakFormatter`.
We could add some knowledge about the custom property info fields form wb_property_info there and pass that as a ParserOption to the IdentifierFormatter. That is perhaps the easiest solution but it encodes knowledge about custom property info fields in `PropertyValueSnakFormatter`.
If we want to have a more flexible system (not sure if we have usecases for that) we should find another way of registering custom options for specific properties.
Outcome of the discussion on 2015-09-16 (Aude, Bene, Marius, JanZ, Daniel):
* The information needed to provide renderings that rely on information associated with a property or are derived from the original value is present in the PropertyValueSnak. It is not present in the DataValue. We currently only have specialiezd rendering logic on the value level, we need to push this up to the snak level.
* Introduce per-datatype / per-format ProvertyValueSnakFormatters, similar to per-datatype / per-format ValueFormatters
* Introduce an IDValueSnakFormatter (for datatype "ID", for HTML and perhaps wikitext output) which uses a lookup service to get the formatter URL to use for linking IDs associated with a specific property. IDValueSnakFormatter could in the future take advantage of derived values (the full URL) being present in the PropertyValueSnak, if/when this is implemented (see T112550).
* IDValueSnakFormatter may or may not use a ValueFormatter internally. For compelx cases, it probably won't.
* Introduce a GenericValueSnakFormatter that dispatches to ValueFormatters based on the data type (and value type). This is what DispatchingValueFormatter currenlty does, DispatchingValueFormatter and GenericValueSnakFormatter could be conflated into a class that implements TypedValueFormatter as well as SnakFormatter.
* Introduce a DispatchingValueSnakFormatter which dispatches to SnakFormatters based on data type.
* Add support for SnakFormatter factory callbacks to DataTypeDefinitions, similar to how factory callbacks for ValueFormatters are already supported.
* Change OutputFormatSnakFormatterFactory to construct a DispatchingValueSnakFormatter based on factory callbacks from DataTypeDefinitions, similar to how OutputFormatValueFormatterFactory. If possible, the fallback logic using automatic escaping used for ValueFormatters should be re-used for SnakFormatters.
* OutputFormatSnakFormatterFactory should fall back to a GenericValueSnakFormatter for any datatype that has no specialized SnakFormatter associated. That GenericValueSnakFormatter would be based on a DispatchingValueFormatter provided by OutputFormatValueFormatterFactory.
* The wbformatvalue API module should get a new parameter "property" which can be used instead of "datatype". When "property" is given together with the value, a PropertyValueSnak can be created and the datatype determiend, so wbformatvalue can take full advantage of datatype specific snak rendering. For B/C, wbformatvalue should still frunction based on the datatype (and even with only the value itself).