W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2010

[Bug 9448] Some bugs with the FTScope in full text

From: <bugzilla@jessica.w3.org>
Date: Sun, 16 May 2010 04:32:29 +0000
To: public-qt-comments@w3.org
Message-Id: <E1ODVWf-0005h5-Fm@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9448


Michael Dyck <jmdyck@ibiblio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdyck@ibiblio.org




--- Comment #1 from Michael Dyck <jmdyck@ibiblio.org>  2010-05-16 04:32:28 ---
> I think that if we have a stringInclude1 which tokenInfo/@startSent !=
> tokenInfo/endSentSent in the match, and then this stringInclude1 will always be 
> right, no matter what the $stringInclude2 is.

That depends on what you mean by "right". The condition in the QuantifiedExpr
will be satisfied for that $stringInclude1 no matter what $stringInclude2 is. 

> On the other hand, if we have a stringInclude1 which tokenInfo/@startSent ==
> tokenInfo/endSentSent in the match, and then this stringInclude1 will always be 
> wrong, because the $stringInclude2 maybe the same of  stringInclude1.

Hmm. So when an "input" match contains a stringInclude that starts and ends
within the same sentence, that match cannot succeed, because the
QuantifiedExpr's condition will return false when $stringInclude1 and
$stringInclude2 are both bound to that stringInclude. Yeah, that's a bug.

(The condition used to begin with
    $stringInclude1 is $stringInclude2 or ...
to "skip over" the cases where the two variables were bound to the same
stringInclude, but that had a bug too: a match containing a single
stringInclude would always succeed.)

We'll have to take another crack at writing that function.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 16 May 2010 04:32:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:42 UTC