Consuming out-of-spec inputs considered harmful - another example

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