7806 2009-10-05 08:13:38 +0000 atom ID element generation for feed entries 2010-10-04 14:57:16 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows NT RESOLVED FIXED TrackerIssue P2 normal --- 1 julian.reschke ian ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 28051 0 julian.reschke 2009-10-05 08:13:38 +0000 28052 1 julian.reschke 2009-10-05 08:16:03 +0000 "Establish the value of id and has-alternate from the first of the following to apply: If the article node has a descendant a or area element with an href attribute that successfully resolves relative to that descendant and a rel attribute whose value includes the bookmark keyword Let id be the absolute URL resulting from resolving the value of the href attribute of the first such a or area element, relative to the element. Let has-alternate be true. If the article node has an id attribute Let id be the document's current address, with the fragment identifier (if any) removed, and with a new fragment identifier specified, consisting of the value of the article element's id attribute. Let has-alternate be false. Otherwise Let id be a user-agent-defined undereferenceable yet globally unique absolute URL. Let has-alternate be false." WRT the last sentence: 1) Why undereferenceable? 2) It should be stated that that URI (not URL) needs to be the same for each run of the algorithm. Otherwise it'll be just a random unique identifier which would violate the requirement in http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6: "The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed." 28520 2 ian 2009-10-20 01:10:02 +0000 > 1) Why undereferenceable? Because if we could have made a dereferenceable URL, we would have done so using the earlier steps. > 2) It should be stated that that URI (not URL) needs to be the same for each > run of the algorithm. Done. 28521 3 contributor 2009-10-20 01:10:53 +0000 Checked in as WHATWG revision r4185. Check-in comment: Clarify that the article id should be stable. http://html5.org/tools/web-apps-tracker?from=4184&to=4185 28547 4 julian.reschke 2009-10-20 06:23:44 +0000 I still do not understand why it says "undereferencable". Is this a normative requirement? If so, for what reason? If not, why mention it all? 28548 5 julian.reschke 2009-10-20 06:24:48 +0000 Also, the text now says: "The same <span>absolute URL</span> should be generated for each run of this algorithm when given the same input." I think this should be a "must". 28551 6 ian 2009-10-20 09:03:13 +0000 > I still do not understand why it says "undereferencable". Is this a normative > requirement? Yes. > If so, for what reason? Because if you gave a ereferencable URL, people might be tempted to dereference it, which would be bad, since it wouldn't point at the article in question. > "The same <span>absolute URL</span> should be > generated for each run of this algorithm when given the same > input." > > I think this should be a "must". Certain UAs won't be able to guarantee that, e.g. because they store no state and thus use a hash of the page and the page changes slightly each time the page is loaded. 28555 7 julian.reschke 2009-10-20 09:15:13 +0000 (In reply to comment #6) > > I still do not understand why it says "undereferencable". Is this a normative > > requirement? > > Yes. > > > > If so, for what reason? > > Because if you gave a ereferencable URL, people might be tempted to dereference > it, which would be bad, since it wouldn't point at the article in question. It's not HTML5's job to dictate this. RFC 4287 already is sufficiently clear about this: "Its content MUST be an IRI, as defined by [RFC3987]. Note that the definition of "IRI" excludes relative references. Though the IRI might use a dereferencable scheme, Atom Processors MUST NOT assume it can be dereferenced." -- http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.6 > > "The same <span>absolute URL</span> should be > > generated for each run of this algorithm when given the same > > input." > > > > I think this should be a "must". > > Certain UAs won't be able to guarantee that, e.g. because they store no state > and thus use a hash of the page and the page changes slightly each time the > page is loaded. In which case they must not generate the ID. "When an Atom Document is relocated, migrated, syndicated, republished, exported, or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource." 28566 8 ian 2009-10-20 10:28:53 +0000 So you're saying it'd be ok to just not have an ID? 28569 9 julian.reschke 2009-10-20 10:45:43 +0000 (In reply to comment #8) > So you're saying it'd be ok to just not have an ID? I did, but I was wrong. No, atom:id is indeed required (not only recommended), but it's also required to be unique and stable. Thus, if you can't generate one by definition you can't create a valid Atom entry. 28577 10 ian 2009-10-20 11:37:37 +0000 So do you think it's better to violate the MUST of having an ID, or the MUST NOT of the ID changing if the UA generates a feed twice? 28581 11 julian.reschke 2009-10-20 12:46:41 +0000 (In reply to comment #10) > So do you think it's better to violate the MUST of having an ID, or the MUST > NOT of the ID changing if the UA generates a feed twice? As I said: "Thus, if you can't generate one by definition you can't create a valid Atom entry." So, if it's impossible to create a conforming Atom document, then do not do it (that is, abort the algorithm). 28603 12 ian 2009-10-20 21:50:07 +0000 Well it's impossible currently to generate a valid Atom feed at all, since taking out the vCard vocabulary meant that there was no way to get the author information from the vCard data. I don't think not showing a feed at all is a good user experience. 28608 13 julian.reschke 2009-10-20 21:58:02 +0000 (In reply to comment #12) > Well it's impossible currently to generate a valid Atom feed at all, since > taking out the vCard vocabulary meant that there was no way to get the author > information from the vCard data. > > I don't think not showing a feed at all is a good user experience. First of all, it absolutely not clear that this is something people really want. But *if* we do this, we need to do it in a way so that a conforming Atom feed is generated. Generating known-to-be-broken feeds imho is not an option. 28615 14 ian 2009-10-20 23:05:58 +0000 I'd be happy to add the vCard stuff back, but you asked me not to. So that's up to you. Should I add back the vCard-based author generation? There's nothing we can do about the unstable IDs in certain UAs, though, as far as I can tell. Making it a MUST instead of a SHOULD doesn't change the fact that certain UAs won't be able to do it. 28658 15 julian.reschke 2009-10-21 06:09:25 +0000 (In reply to comment #14) > I'd be happy to add the vCard stuff back, but you asked me not to. So that's up > to you. Should I add back the vCard-based author generation? No. But not that meta/name=author could be used to obtain author information. > There's nothing we can do about the unstable IDs in certain UAs, though, as far > as I can tell. Making it a MUST instead of a SHOULD doesn't change the fact > that certain UAs won't be able to do it. If certain UA won't be able to do it then the spec should clarify that this is a problem, and UAs must not generate invalid Atom feeds. Also, there's the alternative to remove this part (generating Atom) completely. 28677 16 contributor 2009-10-21 07:50:14 +0000 Checked in as WHATWG revision r4238. Check-in comment: Support <meta name=author> in Atom generation. http://html5.org/tools/web-apps-tracker?from=4237&to=4238 28678 17 ian 2009-10-21 07:53:30 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given above Rationale: I added <atom:author> again, using <meta name=author>. I didn't add a note saying that UAs must not violate Atom, since that's a tautology. It's equivalent to signs that say "unauthorised entry is forbidden". Creating invalid Atom feeds is obviously not valid. 28804 18 julian.reschke 2009-10-22 11:02:32 +0000 (In reply to comment #17) > Rationale: I added <atom:author> again, using <meta name=author>. I didn't add > a note saying that UAs must not violate Atom, since that's a tautology. It's > equivalent to signs that say "unauthorised entry is forbidden". Creating > invalid Atom feeds is obviously not valid. In which case what harm is done by replacing "should" by "must"? 28806 19 ian 2009-10-22 11:06:48 +0000 I'm not adding a requirement that we know can't necessarily be met. If the Atom specification wants to make unsatisfiable requirements, that's its problem. 28807 20 julian.reschke 2009-10-22 11:10:02 +0000 (In reply to comment #19) > I'm not adding a requirement that we know can't necessarily be met. If the Atom > specification wants to make unsatisfiable requirements, that's its problem. This seems to be in conflict with your previous statement that of course "you have to follow other specs". 28810 21 ian 2009-10-22 11:49:44 +0000 How so? 28814 22 julian.reschke 2009-10-22 12:34:28 +0000 (In reply to comment #21) > How so? By saying "should" instead of "must" you suggest that there may be cases where it's acceptable not to follow the requirement. Or, phrased differently: if it's "must" in RFC 4287, why is it "should" here? 28815 23 ian 2009-10-22 12:39:24 +0000 "SHOULD" doesn't mean "MAY". It's a must in the Atom WG because (I presume) they assumed that it wouldn't be difficult to come up with unique IDs, and thus all software could do it. I do not share that assumption. Not following the SHOULD in the HTML5 spec means you are violating Atom, which isn't ok, but that's a problem for the Atom spec. I do not think that being unable to generate a stable ID should be grounds for saying you aren't conforming to HTML, even if you aren't conforming to Atom. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I think the spec is making the right tradeoff here. 28816 24 julian.reschke 2009-10-22 13:16:59 +0000 I'll escalate to a tracker issue. 28901 25 julian.reschke 2009-10-23 16:26:21 +0000 Escalated to http://www.w3.org/html/wg/tracker/issues/86.