Re: more closed-world chatter
Date: Fri, 04 May 2007 14:25:19 GMT
Message-ID: <jnH_h.159449$aG1.54991_at_pd7urf3no>
Jon Heggland wrote:
> paul c wrote:
>
>>Bob Badour wrote: >> ... >>>>Ie., is it a logical mistake to allow the query in the first place? >>> >>>No, it is not a logical mistake. Equality evaluates to false for >>>values of disjoint types. Because 3 is not in your type, the >>>comparison evaluates to false. >> >>Thanks, I feel better now. Still, I'd like to know I could paraphrase >>that query a little more formally, say using D&D <AND>. But the >>stipulation "It is required that if <A,T1> is in Hr1 and <A,T2> is in >>Hr2, then T1 = T2" stymies me, eg., if pricedomain={1,2} and >>anotherdomain={3}, it seems that <AND> isn't defined.
>
>
> Yes, so your query would fail on a type mismatch in A. If it is
> desirable for such a query to succeed (with an empty result), /and/ to
> be equivalent to an <AND>, I believe the (declared) type of the Price
> attribute in the result would have to be a common supertype of the Price
> types in the operands. And that may be slightly counter-intuitive if you
> formulate the query as a RESTRICT.
>
> But why are you unhappy about treating such a query as an error? It can
> be caught at compile-time, and isn't all that different from the error
> I'd expect if I declare a variable of type Price and try to assign it
> the value "red".
> ...
My reason is that I would like, at least on paper, to separate the aspects of an engine that strictly reflect the formal definition of say, D&D Appendix A, from the aspects that reflect taste or preference.
I can see that one layer, if you will, of an implementation, whether compiler or interpreter, could show a notion of exceptions and many users would find the result not "all that different" from one that produced the equivalent of "false". Probably this just reflects a phobia of mine that I think of as "exception creep". Whereas a slightly different interpreter might let the query ride and pass it as is to an engine.
This is perhaps not very clear, but the best I can do at the moment.
>
>>(I realize I could get the "false" answer suggested if only one side of >>the <AND> used the "Items" attribute
>
>
> The Price attribute, you mean? Then the <AND> would be a product, and
> the result empty ("false"?) only by virtue of the Items relation being
> empty. I don't see how this helps in any way.
Sorry, I should have said the Price attribute ...
(Aside - it appears to me that you and Bob B are more or less on the "same page" when it comes to the advantage of sub-typing in dealing with my question. I don't mean to sound as if I'm rejecting that, just questioning whether I am forced to either implement it or to embed elementary exceptions in an engine, ie., forced to implement at least one of them. Also, for some reason I can't explain very well, I seem to view types or domains in a very mechanical way meaning that if a user can define a type that user could also re-define a type which might invalidate all of an existing db's "propositions". Logical limits seem quite important to me and I find both your comments helpful.)
p
p Received on Fri May 04 2007 - 16:25:19 CEST