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. 

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

> 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

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