Re: Use cases

On Thu, 06 Jan 2011 20:06:38 +0100, Sam Ruby <>  
> On 01/06/2011 01:07 PM, Anne van Kesteren wrote:
>> 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.

HTML was invented in 1989. Before 2006 nobody had defined how it ought to  
be processed. In 2010 it was more or less complete. CSS was invented in  
1994. Processing CSS is pretty much figured out and defined by now -- lets  
say 2010 as well, although we still have some loose ends to tie up. 21  
years for HTML. 16 years for CSS. RSS is from 1999. Although it is nowhere  
as successful as HTML, it might very well happen if the various feed  
readers decide it is important. (Since RSS is highly volatile, not used as  
archive format, and has a suitable alternative for publishers, maybe it is  
not all that important and maybe it will disappear.)

> 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.

Isn't one of the problems with RSS that you do not know whether it is HTML  
or XML? E.g. what "&amp;gt;" means? I am not sure how we can solve that  

>> 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.

I would not mind changing XML.

Anne van Kesteren

Received on Thursday, 6 January 2011 19:32:35 UTC