6811 2009-04-14 20:45:08 +0000 [FT] Specification/Weights 2009-06-09 14:27:56 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Candidate Recommendation All All CLOSED INVALID P2 normal --- 1 christian.gruen jim.melton public-qt-comments oldest_to_newest 24727 0 christian.gruen 2009-04-14 20:45:08 +0000 Hi all, a minor one: I noticed that the latest version of the specification allows arbitrary values for weight values. In section "3.1.1 Weights", weights are still limited to absolute values from 0-1000. Was this a deliberate choice or a relict from the old rule? Christian 24906 1 jim.melton 2009-04-23 19:26:14 +0000 Christian, this was a deliberate decision, reached after considerable discussion. There were many opinions expressed but we finally decided that leaving the range of weights to fall between -1000 and +1000 (and the decision of whether or not to support negative weights left implementation-defined) was a good compromise. I'm marking this bug INVALID and request that you mark it CLOSED. 24907 2 christian.gruen 2009-04-23 19:49:12 +0000 Hi Jim, sorry for persisting.. As the current text states that "The weight MUST have an absolute value between 0.0 and 1000.0 inclusive.", I am not sure if implementation-defined, negative weights are considered at this point. Next to that, was there a special reason to use "1000" as value/introduce a restriction at all? I would rather have expected a strict rule (0.0 - 1.0) or no restriction at all. And, another trivia here.. I wonder why a weight value is defined by a "RangeExpr". as I would expect the weight to be always exactly one value. The existing rule... [145] FTWeight ::= "weight" RangeExpr ..would allow expression such as "A" ftcontains "A" weight (1 to 2) which will not make too much sense. Anyway, as usual.. if I have stopped thinking too early - please tell me! Thanks, Christian 24978 3 jim.melton 2009-04-30 22:39:41 +0000 > Hi Jim, sorry for persisting.. No need to apologize; reaching understanding is important. > As the current text states that "The weight MUST > have an absolute value between 0.0 and 1000.0 inclusive.", I am not sure if > implementation-defined, negative weights are considered at this point. Yes, that is why it says "absolute value", just in case the implementation does support negative weights. > Next to > that, was there a special reason to use "1000" as value/introduce a > restriction at all? I would rather have expected a strict rule (0.0 - 1.0) > or no restriction at all. No special reason, just the result of the Task Force's discussion. I also thought that a range (absolute value, of course) of 0.0-1.0 would have been just as good. If I recall correctly, I think somebody said that they knew about, or had, an implementation that used larger numbers. Since it's pretty arbitrary anyway, we decided to go with the 1000 top end. > And, another trivia here.. I wonder why a weight value is defined by a > "RangeExpr". as I would expect the weight to be always exactly one value. The > existing rule... > [145] FTWeight ::= "weight" RangeExpr > ..would allow expression such as > "A" ftcontains "A" weight (1 to 2) > which will not make too much sense. Of course, you're right that it would not make sense to have (1 to 2) as a weight. And, in fact, the language does not support that. The use of RangeExpr is merely an artifact of how the grammar is constructed. > Anyway, as usual.. if I have stopped > thinking too early - please tell me! No problem at all! Jim 24980 4 christian.gruen 2009-04-30 23:18:17 +0000 Hi Jim, > Yes, that is why it says "absolute value", just in case the > implementation does support negative weights. Oh yes.. Sorry, I mixed up "absolute" with "positive". >> Next to >> that, was there a special reason to use "1000" as value/introduce a >> restriction at all? I would rather have expected a strict rule (0.0 - 1.0) >> or no restriction at all. > > No special reason, just the result of the Task Force's discussion. I also > thought that a range (absolute value, of course) of 0.0-1.0 would have been > just as good. If I recall correctly, I think somebody said that they knew > about, or had, an implementation that used larger numbers. Since it's pretty > arbitrary anyway, we decided to go with the 1000 top end. So, once again.. I currently don't see any advantage in restricting the weight at all, so wouldn't make it sense - and simplify the specification - if the restriction was completely discarded and arbitrary values were allowed? The same can be said about negative weights. - Anyway, considering the implementation point of view, it's of course no problem to add a check at this point (although it will be have to be checked every time during runtime, if the weight argument cannot be statically checked). Christian