Thomas Broyer wrote:
Andreas Sewe wrote:
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?
Well, it is not really ignored but irrelevant, since a value for @steps
of "continuous" can be read as making infinitesimal steps. And then
@origin doesn't really matter. You are covering the entire real line, no
matter where you start -- but of course @minimum and @maximum have a say
in this, too. (Note that defaulting @origin to 0 does no harm, though.
No need to make that another special case.)
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".
Note that i is assumed to be an integer, not a natural number; it can be
negative.
You are right, however, with your observation that a negative value for
"steps" should be disallowed. As James already replied, the next
revision of the spec will rectify this.
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" />
[...]
So: there is no need for "origin" and negative "steps" values.
I agree about the negative @steps. @origin is useful, however, even when
its use can be optimized away in some cases.
This is because the above conversion will not work if @minimum is
"unbounded". As you recognized yourself below you, to describe the set
{..., -2.7, -1,7, -0.7, +0.3, +1.7, +2,7, ...}, you need
<r:values minimum="unbounded" origin="0.3" steps="1.0" />
Note that @minimum defaults to "unbounded" -- and is thus not even
needed in the above definition. This is precisely to allow this case to
be written concisely.
(For similar reasons @steps defaults to 0, making it easy to define
singleton sets. That @minimum and @maximum are -- per default -- still
"unbounded" doesn't matter when @steps is 0.
Similar reasoning lead to a default of 0 for @origin. In practice you
should rarely need to specify all four attributes explicitly.)
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.
But what about both @minimum and @maximum being "unbounded"? In this
case you need an origin. In most other cases, however, you can simply
rely on the default of 0. (I expect non-zero origins, except for
singleton sets and a few odd cases like {0.3, 1.3, 2.3, ...}, to be
quite rare in practice.)
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 first two cases will be eliminated from the next revision of the
spec; negative steps are not only counter-intuitive but redundant.
The last falsely assumes that i, in (origin + i * steps), is only
non-negative.
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" />
All true. This proposal, however, deliberately replaces the two elements
r:value and r:range (as present in the current spec) by a single
r:values element, with carefully chosen defaults to make all the common
use cases just as easy to define.
So its purpose is simply to find out which approach -- two elements
(r:value really being redundant) or a single one -- is easier to
understand and implement.
(I guess the workings of the attributes might be a little bit easier to
comprehend if I could find a better name, suitable for the singleton set
case as well, for @origin. Maybe you have a suggestion.)
At any rate, thanks for your comments.
Andreas Sewe
