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 <[email protected]> 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>, > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata-tech >
_______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
