James M Snell wrote:
Andreas Sewe wrote:
Now the current draft defines two elements, r:value and r:range, for
this purpose. Those two elements can be, however, be collapsed into a
single one, and, with cleverly chosen defaults, defining sets using this
new r:values element is IMHO as simple, if not simpler, as with the old
approach. Others might have different opinions, though, which I would
really like to hear about.
Just to note, this seems to be the key disagreement between Andreas and
I on the spec. IMHO, for schemes consisting of a constrained set of
fixed absolute values (like the German grading system which uses 1.0,
1.3, 1.7, 2.0 etc), specifying a collection of overlapping ranges just
doesn't feel right.
Yes, the key disagreement is not whether we should use a single element
or two (I wrote the original proposal to find out atom-syntax's
preference on this), but whether ranges should be allowed to overlap.
Actually, we disagree on three overlapping (pun intended) questions:
1.) Does r:scheme define anything beyond a set of valid rank values (and
an order on them)?
Personally I consider r:scheme's child elements as a specialized
datatype definition language; since we know what use cases we want to
support, so we can come up with a nice, little language to specify how
valid and invalid rank values have to look like.
Now James, AFAIK, additionally wants to be able to attach labels to
r:values and r:ranges. But r:rank's @label attribute does the same job!
The current spec, however, does not state how conflicts are to be
resolved. Furthermore, since you can only reasonably stick labels like
"Good" on non-overlapping ranges, James wants to disallow overlaps. This
somewhat limits the expressiveness of our datatyping mini-language.
IMHO, it is entirely reasonable to attach different r:rank @labels to
different entries, even if they have been rated the same:
<r:rank label="Not a movie I want to watch more than once">1.5</r:rank>
<r:rank label="The popcorn was a lot better than the movie">1.5</r:rank>
In other words, I do not see the need for being able to mechanically
look up a label for every value or range.
2.) How do we handle rank values which do not conform to r:schemes
definitions.
I would simply consider them, r:scheme defining a datatype, as invalid.
(Currently this is already done if a rank value is outside the bounds
defined by its scheme's minimum and maximum.)
James, however, wants to introduce rounding rules: an invalid (as per
r:scheme) rank value is rounded to the nearest valid rank value. Here,
overlapping ranges make it again difficult for the implementer to
determine what the nearest valid value actually is. So James want to
disallow them.
Admitted, there are real-world examples where being able to use invalid
rank values would be nice:
The local university, for example, internally uses grades like 1.19. On
your diploma they only ever show up as 1.0, 1.3, 1.7, and so on. So why
do we require the publisher to throw away some information, namely the
exact grade? Because one rounding rule cannot deal with all the bizarre
rounding schemes in use at schools and universities worldwide. (The
above would be rounded to 1.0, for instance, although 1.3 would be the
nearest valid value.) So, allowing rounding does not gain us that much.
The receiver has to deal with it nevertheless.
3.) And, when it comes to rounding, the issue of @scale comes up. Do we
really need it? I think not; it just complicates things.
So, those are the three main design issues we are currently facing (at
least those I am aware of) -- and feedback from atom-syntax is really
appreciated.
Best wishes,
Andreas Sewe
