W3C home > Mailing lists > Public > www-tag@w3.org > April 2009

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

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 16 Apr 2009 13:14:00 -0400
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <24176A04-7384-48DB-8185-017DD688A2D5@creativecommons.org>
To: ashok.malhotra@oracle.com

On Apr 16, 2009, at 11:26 AM, ashok malhotra wrote:

> 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


OK, good point. Let me see if I can come up with a theory that  
distinguishes libraries from extensions.

You're saying that an external library may be needed in order to  
process a Java program that uses the library, and that's like when an  
OWL processor needs to be correctly extended with a new datatype  
mapping in order to process ontologies that use the new datatype  
mapping.

The difference between datatype mappings in OWL and external libraries  
in Java is that for libraries there is a standard way to supply a  
definition of one, while no such method exists for OWL datatype  
mapping extensions. This means that there are important questions  
about extension-reliant ontologies (such as entailment and  
consistency) that simply can't be answered automatically by OWL  
processors without nontrivial human intervention. With external  
libraries, there is a standard process to go through in order to  
acquire the ability to handle an "extension" - namely, you get ahold  
of an implementation, and put it on your CLASSPATH. This makes a level  
playing field for all processors of the language. OWL ontology imports  
work in pretty much the same way. But for OWL datatype mappings there  
is no such process - the spec doesn't tell you a *method* for  
extending the mapping, only that you can do so. The spec tells you  
what a "correct" implementation of an extension is, but only by  
delegating that question to the owner of the datatype's URI (if I  
understand the spec correctly).

This same pattern could hold for many kinds of extension frameworks.  
Sometimes you don't care (the question you want to answer doesn't  
depend on understanding the extension); sometimes you care and you can  
figure it out (load the library); sometimes you care and you can't  
easily figure it out, and just have to say "I wish you hadn't used  
that extension". The last is the interoperability issue.

You might even say that this distinction - methodical, mostly  
automatic "extension" using the same or referenced specs, vs. thought  
and effort required because there's no standard interface for  
supplying the extension to tools - characterizes the difference  
between a library and an extension.

I'm not saying extensibility is a bad thing; I'm just asking how to  
engineer specs to promote interoperability.

Jonathan
Received on Thursday, 16 April 2009 17:14:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:13 GMT