- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 16 Apr 2009 08:18:27 -0400
- To: "www-tag@w3.org" <www-tag@w3.org>
I just wanted to record (barely in advance of today's telecon) another use case to feed into our language extensibility and error handling use cases, this time in the context of OWL 2 datatype mapping conformance. One side of the disagreement [1] says that tools (consumers) that do not provide a 'strict' mode, in which out-of-spec inputs (e.g. extensions) SHOULD or even MUST lead either to rejection or warning, are a threat to interoperability, because a producer may be lulled by one tool's silent acceptance into assuming that their artifact is valid for all tools, when it's not (because it uses some extension that is not universally implemented). The other side [2] says that this is an unacceptable burden on tool builders. Processors such as validators are welcome to check and complain, of course, but there should be no requirement. I don't want to get www-tag involved in this particular battle, but wanted to note it as yet another example of what a pattern - in particular it has strong echoes of discussions around XML and HTML5. Clearly validation, with rejection (a la XML) being the extreme result, is a nice thing when it leads to better artifacts; the question is who *has* to do it (to be in spec), when, why, at what cost, and to what benefit. The rejection burden can take the form of more effort required to write a tool, as above, or of a cost paid by a consumer to forgo an opportunity. As I've said before I think the browser and embedded-system cases, where there may be no sensible disposition for a warning or rejection and thus little reason to warn or reject, may have different requirements from compiler- and tool-like cases, where there is a moderate chance that feedback from consumer to producer is possible and productive. A compiler is in a position of strength; it can say "fix it or I won't process it" and if you're a producer you have no choice but to make it happy. A browser or embedded system is not; it either gets some value out of the artifact, or the time and effort it has expended to get it and process it are wasted. If the browser could talk back to the server and be listened to, or if the rocket could return to the launch pad and say "I don't understand this extension, fix it or I won't go to Mars", the dynamic would be different. Unfortunately this distinction (ultimately related to differential transaction payoffs and power balance between the two parties) is a property not so much of the tool (consumer) per se, or of the artifact, but of the entire {producer, artifact, consumer} scenario. Jonathan [1] http://www.w3.org/mid/29af5e2d0903312316y60879c74yfb9ce5e23998699@mail.gmail.com starting at "I would like to see a requirement ..." [2] http://www.w3.org/mid/4B2C1BEE-1574-4B87-B44C-81CFE7F3B80C@comlab.ox.ac.uk
Received on Thursday, 16 April 2009 12:19:08 UTC