Re: Use cases

On 01/06/2011 08:10 AM, Henri Sivonen wrote:
> On Jan 5, 2011, at 18:09, Sam Ruby wrote:
>
>> On 01/05/2011 10:51 AM, Henri Sivonen wrote:
>>> On Jan 5, 2011, at 17:38, Sam Ruby wrote:
>>>
>>>> Additionally, there are feed formats, such as RSS 2.0, which do
>>>> not provide a means to clearly identify the mime type of
>>>> descriptions.
>>>
>>> Don't we have Atom to address this problem?
>>
>> Let me know when you personally have recoded all feed producers.
>> :-)
>
> This isn't on my personal todo list. Should I understand that you've
> given up on this being on the collective todo list of the people who
> generate feeds? Or did you never consider it to be on such a
> collective todo list? That is, when we started Atom, did we not think
> we could rid the world of the troubles of RSS?
>
> My view today, which obviously wasn't my view back in 2003, is that
> we shouldn't have done Atom but we should have done to RSS 2.0 (over
> the objections of Dave Winer) what the WHATWG did to HTML (over the
> objections of the W3C membership).

The only problem Atom can solve is the "I want to produce content that 
is valid and capable of being consistently interpreted".  It has solved 
that problem for me.

It can't solve the problem that there are people out there who continue 
to produce content which is not only not valid, not consistently 
interpreted, but can't ever be determined to be valid or consistently 
interpreted as the specs are ambiguous.

Nor can it solve the problem that there are people who won't 
consistently interpret it, not matter what the specs say.

Cycling back to the original statement which you were responding to: as 
an author of a tool that consumes feeds, no Atom doesn't address the 
problem of having to deal with ambiguous content that continues to be 
produced as RSS 2.0 or even RSS 1.0.  Nor could it, even if the AtomPub 
working group had chosen to name the spec RSS 2.0 or published yet 
another incompatible definition for the elements defined in the the 
various RSS 2.0 specifications.

Net: as long as we have both XHTML5 an HTML5 we are always going to have 
content for which the original intent of the author can not be reliably 
determined.  In most cases, interpreting such as HTML5 produces the best 
results.  As such, it makes sense to advocate that people ONLY produce 
XHTML5 which wouldn't degrade gracefully when interpreted as HTML5 IF 
they have a compelling reason to do so.

- Sam Ruby

Received on Thursday, 6 January 2011 16:46:47 UTC