W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2008

[Bug 4719] [FT] editorial: 3.7 Ignore Option

From: <bugzilla@wiggum.w3.org>
Date: Thu, 28 Feb 2008 19:50:59 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1JUomR-0005UO-HX@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4719





------- Comment #4 from holstege@mathling.com  2008-02-28 19:50 -------
(In reply to comment #3)
> The phrases
>     each item Ni (i=1..k)
> and
>     If Ni is not a node,
> indicate that it doesn't have to be a node, so in the phrase
>     let N1, N2, ..., Nk be the sequence of nodes that UnionExpr evaluates to
> "nodes" should presumably be changed to "items".

Yeah. An alternative is to just insist that everything here be nodes. Not a
node => type error.  In fact, this is the semantics that fts:reconstruct has
due to its function signature. Which makes the offending sentence about what
to do about non-nodes moot: it should just be deleted.

> "omits each item Ni (i=1..k) that is not Ij"
>     The "that is not Ij" part doesn't agree with fts:reconstruct.
>     I think fts:reconstruct's interpretation is less surprising.

It took me a bit to see what the difference was, given that fts:reconstruct
uses the "is" operator as well.  The "is" in "is not" above refers to the
"is" operator.  The difference is in the case where a descendent node of
Ij "is" some Ni, yes?  Can you think of a simple way to say this? 

> "If Ni is not a node, it is ignored, as "is" does not apply to non-nodes."
>     The second part is kind of a non-sequitur. I'm guessing you're talking
>     about XQuery's "is" operator, but there isn't a use of it nearby. And 
>     even if there were, it wouldn't really explain much. I suggest just 
>     ending the sentence at "is ignored".

Moot, given observation above.

> > Point [1] was considered at F2F 2008-01-24 and we declined to do so, on the
> > grounds that FTIgnoreOption is not a core feature.
> 
> Hm. Well, looking at 5.2.13 and 5.2.14, it seems that FTIgnoreOption and
> Scoring are about equivalent in their core-ness, but that doesn't prevent 2.3
> Score Variables from being close to section 2.2.
> 

Well "core" was a poor choice of words. The thing is that it isn't the first
thing you think of when you think about full-text querying.  Matching and
scoring are much more central.

> Look at it this way: syntactically, FTIgnoreOption is not part of FTSelection,
> it's part of FTContainsExpr. So [3.7 Ignore Option] doesn't belong in [3
> Full-Text Selections], it belongs in [2.2 Full-Text Contains Expression].

Technically true, but giving such prominence to it doesn't seem like a win,
overall, at least not to me.
Received on Thursday, 28 February 2008 19:51:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:50 GMT