On 5/5/06, Andreas Sewe <[EMAIL PROTECTED]> wrote:
You mean r:rank, right? Well, the purpose of r:scheme (and its child elements) is to describe the ordered set from which r:rank's values a picked. Think of it as a datatype definition geared specifically at describing those sets of numbers commonly encountered in grading schemes.
Why don't you call it that in the draft?
> This conflicts with the atom:author field. Why not @id, @domain, etc. Well, I am not sure what you mean here, but as for @domain you have to realize that a single scheme can be used to rank entries within more than one Ranking Domain (e.g.., within several feeds). Changing @name to @id might cause confusion, since attributes called "id" commonly contain NCNames, not IRIs. I suggest to James using an r:id child element of r:scheme, instead, to mimic atom:id, but somehow he doesn't like the idea. But maybe you can come up with a better name for @name (no pun intended).
Ranking Domain. I'm still not sure what that means.
>> An Atom feed element MAY contain any number of r:scheme elements. >> A feed MUST NOT contain more than one r:scheme element with the >> same name. > > Well, you have all of these child elements that can change the effect > of the element, so why would you want to ban this behavior? I don't understand the above. :-( Can you please clarify your objection. Thanks.
I don't see the interoperation problem the MUST NOT is preventing. -- Robert Sayre "I would have written a shorter letter, but I did not have the time."
