Re: PaceDateSamRuby +1

[Dare Obasanjo <kpako@xxxxxxxxx>]

--- Asbjørn_Ulsberg <asbjorn@xxxxxxxxxxxxxx> wrote:

> On Thu, 12 Aug 2004 11:11:28 -0700 (PDT), Dare
> Obasanjo <kpako@xxxxxxxxx>  
> wrote:
> 
> > For example, in NetNewsWire if the pubDate is
> changed in the feed the
> > item's display date in the application is changed
> while this is not
> > the case in RSS Bandit. Which behavior is correct
> and why? These
> > are the kinds of questions a spec is supposed to
> answer.
> 
> Then please help us answer them. I can't see how
> either PaceDateKenMacLeod  
> or PaceDateSamRuby specifies this any better than
> the other paces. They  
> both state what the consumer MAY do with the
> date(s), but I can't see how  
> that improves interoperability or consistency
> between clients. In  
> PaceDateAsbjornUlsberg2, I've added some text
> covering this as well.

There's only one date in PaceSamRuby. I don't see how
any ambiguity or interoperability issues can arrive
from misinterpreting a single date. The one ambiguity
from previous experience in RSS is resolved because it
is explicitly stated that the value of the date field
can change. 

> To improve consistency between clients, we need to
> say what the dates  
> specifically should represent. Is it e.g. possible
> to agree on what date  
> should be the «sort date»? I think not, since what
> the client sorts on  
> most likely is modifyable by the user.
> Is it possible to agree on what date should work as
> the «display date»?  
> Perhaps. But won't the date available be displayed,
> no matter what that  
> is? If a Pace with multiple dates is chosen, which
> dates have precedence  
> over the others? Is the subjective date more
> preferrable as a display date  
> than the date of formal issuance?
> 

It is silly for the spec to try to dictate which dates
clients should display to users or use for sorting.
You can spec it if you want, I'll ignore it in my
application and do what I think is best for my users
based on their feedback. 

By the way none of these problems exist if we just
adopt PaceSamRuby. 

> Questions like these needs to be answered. They are
> not answered in any  
> date paces yet. As I don't use any common RSS
> aggregators, I'm not the  
> right man to answer these questions. I really don't
> care what aggregators  
> do with the dates. The can convert them to linux
> timestamp, add them all  
> together and divide them by pi for all I care.

So why are you holding up consensus by ratholing on
these points then? 

> What I care about is what the publishers do with the
> dates, which is why I  
> have used so many words in my pace(s) to explain how
> publishers should  
> treat each date element. If there's still not enough
> text in my pace(s)  
> about how publishers should treat the date elements,
> please let me know  
> what's missing.

What is so wrong with using the existing and very
clearly defined dates in
http://purl.org/rss/1.0/modules/dcterms/ 

They cover the dates in the significant publishing
scenarios as well as define mechanisms for versioning
and superceding. 


=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.


		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail