Sounds a lot like a restatement of Postel's Law
https://en.wikipedia.org/wiki/Robustness_principle
Tom
On Fri, Feb 5, 2016 at 7:10 AM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Hi all!
In the context of introducing the new "math" and "external-id" data types, the question came up whether this introduction constitutes a breaking change to the data model. The answer to this depends on whether you take the "English" or the "German" approach to interpreting the format: According to < https://en.wikipedia.org/wiki/Everything_which_is_not_forbidden_is_allowed%3..., in England, "everything which is not forbidden is allowed", while, in Germany, the opposite applies, so "everything which is not allowed is forbidden".
In my mind, the advantage of formats like JSON, XML and RDF is that they provide good discovery by eyeballing, and that they use a mix-and-match approach. In this context, I favour the English approach: anything not explicitly forbidden in the JSON or RDF is allowed.
So I think clients should be written in a forward-compatible way: they should handle unknown constructs or values gracefully.
In this vein, I would like to propose a few guiding principles for the design of client libraries that consume Wikibase RDF and particularly JSON output:
- When encountering an unknown structure, such as an unexpected key in a
JSON encoded object, the consumer SHOULD skip that structure. Depending on context and use case, a warning MAY be issued to alert the user that some part of the data was not processed.
- When encountering a malformed structure, such as missing a required key
in a JSON encoded object, the consumer MAY skip that structure, but then a warning MUST be issued to alert the user that some part of the data was not processed. If the structure is not skipped, the consumer MUST fail with a fatal error.
- Clients MUST make a clear distinction of data types and values types: A
Snak's data type determines the interpretation of the value, while the type of the Snak's data value specifies the structure of the value representation.
- Clients SHOULD be able to process a Snak about a Property of unknown data
type, as long as the value type is known. In such a case, the client SHOULD fall back to the behaviour defined for the value type. If this is not possible, the Snak MUST be skipped and a warning SHOULD be issued to alert the user that some part of the data could not be interpreted.
- When encountering an unknown type of data value (value type), the client
MUST either ignore the respective Snak, or fail with a fatal error. A warning SHOULD be issued to alert the user that some part of the data could not be processed.
Do you think these guidelines are reasonable? It seems to me that adopting them should save everyone some trouble.
-- 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