Re: UNSAID - two test cases (dawg:unbound, issues#useMentionOp)

On Wed, 2004-12-22 at 10:26 +0000, Seaborne, Andy wrote:
> ==== Case 2:
> This is a great test case from Steve:
> "find all the people with exactly one known email address"
> might be:
> SELECT ?person
>    (?person :email ?e1)
>    UNSAID { (?person :email ?e2) AND ?e2 NE ?e1 }
> but also optionals+constraints can do it:
> PREFIX : <>
> SELECT ?person
> WHERE  (?person :email ?e1)
>     OPTIONAL { (?person :email ?e2) AND ?e2 NE ?e1 }
>     AND ! &dawg:bound(?e2)
> using the same method Steve had of using optional, then inverting the sense
> of the match with dawg:bound.

I thought dawg:bound was sort of wishful thinking in an earlier
message... I had trouble finding it in the editor's draft...
do you mean isBound in 11.2.2?

"Return true if its argument, which may be an expression, is defined.
NaNs and INFs count as defined."

Surely the arguments to operators are the *values* of expressions,

for example

"fn:compare Compare two strings.. Returns -1, 0, or 1, according to the
rules of the collation used."

If I write
  fn:compare(?x, "abc")

it's not comparing the 3-character string "?x" with the
5-character string '"abc"'; rather, it's comparing whatever
?x is bound to with the 3-character string "abc", right?

So the specification of isBound has use/mention bugs... operators
can't see variable names. isBound would have to be a language
keyword, like UNSAID or SOURCE.

I'm afraid dtype() has the same problem.

I think the safest thing about this issue
is to take them out.

More related problems...  under extensible value testing...
"A function can test some condition of bound and unbound variables
or constants." I don't see how that makes sense. Functions
can't see unbound variables; they can only be evaluated once
variables are bound. A function is a mapping of some values
to other values.

Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 22 December 2004 14:43:15 UTC