This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.7 Ignore Option [1] position of section Given that an FTIgnoreOption can only occur as part of an FTContainsExpr, I think this section should be close to 2.2. [2] para 1 "The ignore option specifies a set of nodes whose content are ignored" s/content/contents/ [3] "(see FTContainsExp)" s/Exp/Expr/ [4] "Let N1, N2, ..., Nk be the sequence of nodes of the search context." If the search context contains atomic values, this would seem to exclude them from the new search context. [5] para 2 "Now, let I1, I2, ..., In be the sequence of items that UnionExpr evaluates to. For each Ni (i=1..k) a copy is made..." To get the quantification right, change to: For each Ni (i=1...k), let I1, I2, ..., In be the sequence of items that UnionExpr evaluates to. A copy of Ni is made... It might be even better if you pulled in the stuff about evaluating UnionExpr from the preceding para. [6] "that is not Ni" So "without content ." has no effect?
Further to [5]: The spec should probably say what happens if an Ij is a non-node, i.e. if the value of the UnionExpr contains one or more atomic values. (Presumably, the choices are: raise an error, skip it, or work with it).
Fixed, as part of fixes to 4728 or as editorial changes as suggested. 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.
(In reply to comment #2) > Fixed, as part of fixes to 4728 or as editorial changes as suggested. 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". Note that you could say something like let N1, N2, ..., Nk be the nodes in the sequence of items that UnionExpr evaluates to and then subsequently know that Ni is a node. "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. "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". > 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. 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].
(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.
At meeting 166, the FTTF made a couple of decisions. 1) Re comment #1: If the Ignore expression yields non-nodes, raise a type error. 2) Re comment #3: > "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. Drop "that is not Ij". (So if some search context item Ij is an ignored node Ni, it will be ignored.) I have committed these two changes to the document.
re [1]: At meeting 167, the FTTF decided not to change the position of section 3.7 Ignore Option. Therefore, I'm marking this bug resolved-fixed, and closing it.