[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: Updated Index draft


Antone Roundy wrote:


I think a ranking without a domain is pretty much useless--or at least likely to lead to problems downstream--so that case doesn't need to be covered. More on that below.

Agreed.

 <xhtml:html>
   ...
   <xhtml:body>
     <atom:feed>
       <atom:id>Feed1</atom:id>
       <i:domain>#</i:domain> <!-- document ranking domain -->
       <atom:entry>
         <atom:id>A</atom:id>
         <i:rank scheme="priority">50</i:rank>
         <i:rank scheme="priority" domain="#">20</i:rank>
       </atom:entry>
       <atom:entry>
         <atom:id>B</atom:id>
         <i:rank scheme="priority">25</i:rank>
         <i:rank scheme="priority" domain="#">40</i:rank>
       </atom:entry>
     </atom:feed>
     <atom:feed>
       <atom:id>Feed2</atom:id>
       <i:domain>#</i:domain> <!-- document ranking domain -->
       <atom:entry>
         <atom:id>C</atom:id>
         <i:rank scheme="priority">50</i:rank>
         <i:rank scheme="priority" domain="#">30</i:rank>
       </atom:entry>
       <atom:entry>
         <atom:id>D</atom:id>
         <i:rank scheme="priority">25</i:rank>
         <i:rank scheme="priority" domain="#">10</i:rank>
       </atom:entry>
     </atom:feed>
   </xhtml:body>
 </xhtml:html>


In this example, the domainless rankings were added when the XHTML document was created, right? So the XHTML document is essentially an aggregate feed, just not in Atom format. Would it not make as much or more sense to mint an ID for the document (call it the ID of a "virtual Atom Feed Document" if you don't actually create an aggregate feed) and use it to scope those i:rank elements? If, somehow, someone were to pull the atom:feeds out of the XHTML document (if atom:feed getting embedded into xhtml:body is going to happen, then is not atom:feed getting extracted from xhtml:body also likely?) and aggregate them with other feeds with domainless i:rank elements, the scopes of those elements would get mixed.

Yes, but we cannot reliably dictate that containing documents must contain atom:id elements simply because we have no control over the definitions of those containing documents. And yes, if someone pulls the feed out of the XHTML and uses it somewhere else, any ranks in the document scope will be affected. I do not believe that this is a deal-breaker, however.. it's just something that folks using the ranking mechanism need to be aware of so that they can make the appropriate decisions about how and when to properly use the document ranking domain versus a domain that explicitly scoped to a given ID.

* Since the urn:(netflix|amazon).com/reviews schemes are feed independent, it is not necessary to indicate a feed (or "domain") in this case.
* For a feed-specific scheme, like natural order, the feed ID would be included like this (so that if these entries were aggregated, it would be clear that the i:order elements were relevant to the source feed, not the aggregate feed):

The goal of @scheme is to identify the type of ranking to apply while the goal of @domain is to identify the scope of the ranking. I do not believe that it is a good idea to conflate the two.


Okay, I've come to agree with that while writing and editing this message. Note however that "fivestar" also indicates multiple things:

1) Higher numbers are "better"
2) The range is 0 to 5 (BTW, if this is limited to integers, how will you handle things like 3.5 stars, which are common in that type of rating system? Maybe decimal values need to be allowed.)
3) Hint: you might want to display the value as stars

#1 is the only one needed for sorting of entries. #2 would be useful if the feed reader wanted to display some sort of graphical element to indicate the ranking. #3 might be slightly useful, but except for the most popular schemes, would probably be ignored. Perhaps all of these should be separated, a la:

<i:ranking-scheme
    label="Amazon rating"
    order="descending"
    min-value="0"
    max-value="5"
    symbol="stars"
    domain="urn:amazon.com/customer-rating"
/>

Minutes before I received this note I had a similar thought that a scheme definition could be useful -- although that get's us quite close to the territory of the RSS simple list extensions (not that it is a bad thing). The symbol attribute is a bit strange. I'd rather let the application determine how it wants to display the rank. The label, order, min and max values and domain attribute are fine. And yes, regarding #2, allowing decimal values would likely be a good idea... doing so would also allow us to do ratings that are based on a 0-1 fractional scheme (e.g. percentages, etc). Negative values should also be allowed.

...
<entry>
<i:rank domain="url:amazon.com/customer-rating">3</i:rank>

...where @domain is the feed/id of the feed if there's just one feed in scope, or a value that won't be duplicated by any feed/id otherwise (if one can mint a unique feed id, surely one can also mint a unique id that won't be used for a feed).

I'd suggest that i:ranking-scheme/@domain either default to the containing feed/id (or the one from atom:source, if it exists) or be required, i:rank/@domain be required, @order default to ascending, @min-value default to 0, and the rest of the attributes be optional with no defaults.


I'm liking these suggestions...

The i:ranking-scheme element would appear within the atom:feed. If the @domain attribute is missing, the domain is automatically mapped to the id of the feed. If the @domain attribute is a same document reference, the domain is mapped to the document scope.

 <!-- Ranking Domain is assumed to be equal to the feed's atom:id -->
 <i:ranking-scheme ... />

<!-- Ranking Domain is scoped to the containing document -->
<i:ranking-scheme ... domain="http://www.example.com"; xml:base="http://www.example.com"; />

The meaning of the @order attribute needs to be clearly articulated. It is NOT an indicator of how applications should display the elements rather an indicator of how to interpret the rank values (e.g. highest number is most significant, lowest number is most significant). With that in mind, I'm wondering if @order should be named something like "significance" instead. That is, for instance, if significance="descending", lower rank values have a lower significance that higher rank values.

<feed>
<i:ranking-scheme
label="Five Stars" significance="descending"
min-value="0"
max-value="5"
domain="urn:amazon.com/customer-rating" />
<entry>
...
<i:rank domain="urn:amazon.com/customer-rating">5</i:rank>
</entry>
<entry>
...
<i:rank domain="urn:amazon.com/customer-rating">3</i:rank>
</entry>
</feed>

Any given domain SHOULD only ever be associated with a single ranking-scheme. If more than one ranking-scheme is associated with the same domain, it is up to the application to select which of the schemes to apply while ignoring the others.

If two feed documents specify conflicting ranking-schemes associated with a single domain, and an application wishes to combine the feeds and rank them as a single set, it is up to the application to figure out how to reconcile the conflict.

If a ranking-scheme cannot be found for a given domain, the i:rank should be ignored.

The spec *could* (should?) provide a mechanism for registering ranking-schemes with IANA in order to allow feeds to use i:rank's with well known domains without having to include the ranking-scheme element. The domain URI value of these registered ranking-schemes should be reflective of their IANA registration, for instance: "http://www.iana.org/assignments/rankings/generic-customer-rating";

 <i:ranking-scheme
   label="Importance"
   significance="descending"
   min-value="0"
   max-value="100"
   domain="http://www.iana.org/assignments/rankings/importance"; />

<feed>
<entry>
...
<i:rank domain="http://www.iana.org/assignments/rankings/importance";>50</i:rank>
</entry>
<entry>
...
<i:rank domain="http://www.iana.org/assignments/rankings/importance";>30</i:rank>
</entry>
</feed>

Registering ranking-schemes in this way would help to mitigate the potential for conflicting ranking-scheme definitions across multiple feeds as it would provide a single, authoritative source for resolving the domain's ranking-scheme.

- James