W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: looking for the use case for HTML->Atom conversion

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 15 Apr 2010 20:36:11 +0200
Message-ID: <4BC75C9B.1000107@gmx.de>
To: Edward O'Connor <hober0@gmail.com>
CC: HTML WG <public-html@w3.org>
On 15.04.2010 20:00, Edward O'Connor wrote:
> ...
> no.com/projects/hatom2atom/?url=http://edward.oconnor.cx/tests/html5/ISSUE-86/hAtom-no-id.html&ctype=application/atom%2Bxml&tidy=yes
>
> So converting hAtom to Atom with hAtom2Atom suffers from worse Atom
> conformance issues than the HTML5 spec's HTML to Atom algorithm. Empty

Thanks for the data. What I hear is that you have valuable feedback for 
hAtom, and that the authors of hAtom need to address that.

It also confirms that it's impossible to create valid Atom documents if 
the source document does not contain sufficient information (and you 
don't want to maintain local state).

> <atom:id/>s are worse than unstable<atom:id>s in my book. Software that

Empty atom:id elements are a conformance violation that can be easily 
detected, non-stable atom:id elements just cause weird behavior in the 
consumer. Both are bad, but missing or empty atom:id elements might be 
even preferable because the consumer will know that something is wrong.

> implemented the Entry Permalink fallback correctly would suffer from a
> worse<atom:id>  story too, because in the above scenario all of the
> distinct<atom:entry>s in the feed would share the same<atom:id>.
> ...

Later on:

> I wouldn't read that much into it. This algorithm, like everything else
> in the spec, has room for improvement. I think my suggestion above might
> be such an improvement. Let's wait to see if Ian agrees to change the
> algorithm as I've suggested. If he does, ISSUE-86 would become a
> non-issue.

It's better conformance-wise and would address my main concern (but not 
the other problem with the "unreferencability requirement").

However, for any page that isn't hand-authored, I'd expect IDs to be 
present for either all entries or none of them, in which case the end 
result would be the same as for not producing the feed in the first place.

Anyway, we already have two change proposals; one for dropping the 
section completely, one for fixing just the two issues I spotted. Do you 
want to make a third one?

Best regards, Julian
Received on Thursday, 15 April 2010 18:37:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT