Thomas,
Everything you write below speaks precisely to the point as to why I
would prefer *not* always defining r:scheme in terms of ranges --
especially potentially overlapping ranges. Ranges can be complicated.
In the current spec, the use of origin is dependent both on the
significance of the scheme (ascending or descending) and on whether or
not minimum/maximum values are specified.
If significance=descending and maximum is specified, then origin ==
maximum and step counts backwards. Larger numbers have lower significance.
If significance=ascending and minimum is specified, then origin ==
minimum and step counts forwards. Larger numbers have greater significance.
Stepped range values should always be calculated relative to the least
significant value. If the least significant value is not specified,
origin may be used to provide an alternative starting point. If the
least significant value is specified, specifying an origin is unnecessary.
One point that needs to be clarified in the spec. Step MUST be a
positive decimal value.
Also note that in the current spec, the step is used only to identify
the increment at which values in the range are considered significant
for purposes of comparing ranks. When producing ordered sets of ranked
entries, intermediate values that fall in-between steps are considered
equivalent to the nearest least-significant, in-step value.
For instance, given the following range in a scheme with ascending
significance,
<:range minimum="0.00" maximum="1.00" step="0.10" />
The set of values 0.01...0.09 is considered equivalent to the value 0.10.
This is a point that Andreas and I have disagreed on. His argument has
been that feed publishers should only output r:rank values that
precisely match the step and origin. e.g. a rank of 0.15 would be
invalid given the above scheme. With this approach, overlapping ranges
are less of a problem so long as all of those ranges use the same size
step and specify different origins.
I, on the other hand, feel that intermediate rank values are acceptable,
in which case, ranges MUST NOT overlap because you'd never be able to
precisely determine the range to which the value belongs.
For schemes consisting of a constrained set of fixed, absolute values,
dealing with all this range stuff is just overkill. If there are only a
handle of acceptable values, we should just list those specific values
and be done with it.
- James
Thomas Broyer wrote:
>
> 2006/5/5, Andreas Sewe <[EMAIL PROTECTED]>:
>> If the value of the "steps" attribute is "continuous" the set of rank
>> values defined by the r:values element is
>>
>> { x | minimum <= x <= maximum }.
>
> And @origin is ignored?
>
>> Otherwise the set of rank values defined by the r:values element is
>>
>> { x | minimum <= x <= maximum,
>> x = (origin + i * steps) for some integer i }.
>
> If "i" and "steps" are positive values, then "x" will always be
> superior to "origin".
>
> If "origin" is superior to "minimum", then "minimum" is not needed, as
> "origin" *is* the minimum value.
> If "origin" is less than "minimum", then "x" will always be superior
> to "origin + i*steps" for which "i" is the minimum integer value
> verifying "origin + i*steps >= minimum"; this is quite easy to
> compute, so there's no real need for "minimum" either in this case:
> the following r:values are all equivalent:
> <r:values minimum="1.0" maximum="4.0" origin="0.3" steps="1.0" />
> <r:values minimum="1.0" maximum="4.0" origin="1.3" steps="1.0" />
> <r:values minimum="1.3" maximum="4.0" steps="1.0" />
> <r:values minimum="1.3" maximum="3.3" steps="1.0" />
>
> If "steps" is a negative value, its easy to compute the same set of
> values using the minimum allowable value as the "origin" (or
> "minimum") and a positive "steps". The following r:values are all
> equivalent:
> <r:values minimum="1.0" maximum="4.0" origin="3.3" steps="-1.0" />
> <r:values minimum="1.0" maximum="4.0" origin="0.3" steps="1.0" />
>
> So: there is no need for "origin" and negative "steps" values.
>
> There is however one case where that (converting a negative "steps"
> value into a positive one) could not be possible: when "minimum"
> equals "unbounded".
> Couldn't it be spec'd that:
> - if "minimum" is provided and not "unbounded", then "steps" counts
> upwards from "minimum" to the greatest value inferior to "maximum"
> - if "minimum" is not provided or "unbounded", then "steps" counts
> downwards from "maximum" to negative infinity.
>
> In other words, people transitioning from origin and/or negative-steps
> have to do the following:
> - if "steps" is negative and "minimum" is not "unbounded", replace
> "minimum" with the smallest allowable value and use a positive "steps"
> value
> - if "steps" is negative and "minimum" is "unbounded", replace
> "maximum" with the value of "origin" and use a positive "steps" value
> (which will count downwards to negative infinity)
> - if "steps" is positive, replace "minimum" with the value of "origin"
>
>> The following examples illustrate how different sets of rank values can
>> be defined by means of a single r:value element:
>>
>> <!-- The rank value 1 -->
>> <r:values origin="1" />
>
> Could be expressed as:
> <r:value value="1" /> <!-- a ew r:value element -->
> or
> <r:values value="1" /><!-- a new "value" attribute -->
> or with the following r:values:
> <r:values minimum="1" maximum="1" />
>
> --
> Thomas Broyer
>
>
