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

Did you means that the 'strict' mode would disallow or flag, for 
example, use of an external library in Java or
the use of user-defined functions in XQuery or XSLT?  Seems a bit 
extreme to me.
All the best, Ashok


Jonathan Rees wrote:
> 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 15:29:22 UTC