W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: Use cases

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 06 Jan 2011 15:45:40 -0500
Message-ID: <4D2629F4.9030102@intertwingly.net>
To: Anne van Kesteren <annevk@opera.com>
CC: Henri Sivonen <hsivonen@iki.fi>, public-html-xml@w3.org
On 01/06/2011 02:27 PM, Anne van Kesteren wrote:
> On Thu, 06 Jan 2011 20:06:38 +0100, Sam Ruby <rubys@intertwingly.net>
> wrote:
>> 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.)

Apparently you are 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.
>
> 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 here.

RSS 2.0 has many problems.  Many of them outside the scope of this task 
force.  The existence of problems outside of the scope of this task 
force doesn't make the problems that do affect the topics that this task 
force is intended to address.

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

I'm not sure why you are bringing this up in this context.  Would you 
suggest changing XML in a way that reduces this down to one path?  In 
particular, how would the XML that you envision parse the following 
fragment?

<rss version="2.0">
	<channel>
		<title>Scripting News</title>
		<link>http://scripting.com/</link>

I mention this as we recently discussed how HTML5 parses link tags:

http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0107.html

- Sam Ruby
Received on Thursday, 6 January 2011 21:05:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 January 2011 21:05:22 GMT