Re: Conformance was Re: apologies and TEST update

Jim:
>jeremy, you missed my point completely. 

I'm beginning to see where you're coming from ...

I think you are right to suggest that I was too strict, but I still think 
you're too liberal!

I think we agree on the definition of OWL Lite and OWL DL documents, and I 
think we agree that it is appropriate for the WG to define such things 
precisely. I note that the defns are syntactic in nature, if somewhat ugly.

I find your crawler use case compelling.

This suggests an OWL DL [Lite] compliant system SHOULD be able to read all OWL 
DL [Lite] documents (if any) and SHOULD write OWL DL [Lite] output (if it 
produces any OWL output).

This means that for an editor it cannot simply take a garbage in garbage out 
attitude, in contrast with some of your statements:
e.g.

>I wouldn't expect tools to be called OWL 
>Lite compliant if they do inappropriate things given an Owl Lite 
>document.  Given an OWL Full document, I don't see why I should 
>expect them to do appropriate things at all - be nice if they barf on 
>it in some sense (error messages would be appropriate), but I don't 
>see that they should have to do that to prove compliance.

It seems that when interoperating between different systems the case where an 
OWL Full document is fed to an OWL Lite system is going to happen frequently. 
We need to be sure that interoperation occurs. GIGO is not interoperation.
Appropriate behaviour may include:
+ correctly understanding the document and continuing 
+ recognising the document as outside the domain of the tool and barfing

Notice that I have weakened my position to "outside the domain of the tool", 
i.e. the tool can accept some set of documents, which includes all of OWL 
Lite, and the tool can recognise whether a document is in that set or not.


>But, 
>this is assuming it was given a document in which the types were 
>correctly separated in the first place.  If not, I don't know what my 
>tool should do (nor should I - it was handed an inappropriate 
>document)


remind me *not* to use your tools :)
Of course this happens, but it's a bug - inappropriate behaviour on broken 
input is just as serious a bug as inappropriate behaviour on correct input.

Personally, my preference for appropriate behaviour on broken input is to 
barf.  I recognise that many people prefer a mode in which the tool tries to 
patch up and continue, and in practice I code that sort of behaviour as well; 
but barfing is always the long stop. I prefer tools that have a strict mode 
in which they barf early and give up and the patch up code is disabled.

From the user's point of view being told that the input was broken is real 
helpful; the more precise the error message the better. But you are right it 
does not need to be universal - it certainly needs to be implemented 
somewhere before we exit CR.

See you soon

Jeremy

Received on Tuesday, 7 January 2003 03:16:42 UTC