Re: Use cases

On 01/06/2011 01:07 PM, Anne van Kesteren wrote:
> On Thu, 06 Jan 2011 17:45:16 +0100, Sam Ruby <rubys@intertwingly.net>
> wrote:
>> 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.
>
> The problem you describe here is one RSS has and nobody has cared enough
> about to fix as of yet. That is because there is no good specification
> for RSS. Atom reinvented the wheel without fixing the original problem.
> And although it has seen greater success than similar attempts (XHTML2,
> original Cookie RFC, and Cookie2 RFC come to mind) it does indeed not
> fix the original problem. (I think my name might be somewhere on the
> Atom RFC. :/)
>
> I am not sure however to what extent we should care about RSS not being
> specific about things being HTML or XML. It seems that is something the
> RSS community ought to solve in the long run. (Or RSS vanishes, but that
> seems unlikely.)

As of yet?  You can't be serious.

This task force is about HTML, XML, and the mixing of the two.  Feeds do 
exactly that.  I don't believe it makes sense for us to be building a 
corpus of use cases based on the presumption that RSS 2.0 is either 
going to go away -- or ever be fixed.  I suggest that anybody who 
believes otherwise should have the burden of proof in identifying a 
credible plan that has a plausible chance of actually addressing the 
problem in a reasonable time frame.

>> 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.
>
> I still think cross-media-type compatibility (i.e. polyglotness) is a
> bad idea and should not be advocated at all. Most people have no idea
> what is going on and we want to have one way to interpret documents.

As long as we have both application/xhtml+xml and text/html, we will 
always have at least two ways to interpret documents.  The two possible 
strategies for mitigating this would be to either minimize or maximize 
the set of documents which can be successfully parsed as either.

Given that HTML5 doesn't make a practice of rejecting any input, only 
one of those two paths is viable.

- Sam Ruby

Received on Thursday, 6 January 2011 19:08:13 UTC