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

Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 15 Apr 2010 11:08:14 +0200
Message-ID: <4BC6D77E.1030803@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Sam Ruby <rubys@intertwingly.net>, "public-html@w3.org WG" <public-html@w3.org>
On 15.04.2010 10:49, Ian Hickson wrote:
> ...
> Storing an ID doesn't work when you're on a read-only medium.


> A hashing mechanism by which we can generate an ID from a DOM tree would
> end up making identical posts in unrelated Atom feeds have the same ID,
> and would mean that minor edits (e.g. typo fixes) would generate new IDs,
> both of which would cause all kinds of problems, as Sam pointed out.


> Not producing a feed doesn't solve the problem of producing a feed.

Sometimes a problem is insolvable, in which case pretending that it's 
solved isn't helpful.

> Therefore if we make this a MUST in the HTML spec, we are just adding a
> requirement that will in some cases be ignored. This is functionally
> equivalent to a SHOULD, which is what the spec has now.

No, it's not equivalent. Saying "SHOULD" gives the impression that there 
are valid reasons to ignore the requirement. Atom, like it or not, says 
that there are no such reasons.

> If you prefer a process-based argument: we can't progress past CR if we
> can't find two interoperable implementations of every feature. If one of
> the features is "you must make consistent IDs for HTML<article>s when
> converting them to Atom, even if they are slightly modified from time to
> time, and even if you have no persistent storage, and you must not create
> IDs that conflict with other entries", then we won't be able to exit CR,
> because that requirement is not implementable.

So we know it's broken, but don't remove it until then?

>> What the Atom spec is the result of VERY long discussions, and when it
>> says MUST then it's because the Working Group really wanted it that way.
> And nothing we do here can change what the Atom spec says. I don't see the
> problem. We're not making it ok to create invalid feeds. We're just saying
> that if you can't create a valid feed, that's an Atom conformance error
> and not an HTML conformance error.

Actually, the spec doesn't say that. It's just silent on the issue, and 
misleads readers into thinking there may be no issue at all.

Let me ask a question: do you consider it to be acceptable tp produce 
broken Atom feed documents when the HTML source doesn't have sufficient 
information to produce a valid feed?

Best regards, Julian
Received on Thursday, 15 April 2010 09:08:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC