This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"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."
> 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.
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
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?
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".
> 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.
(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."
So you're saying it'd be ok to just not have an ID?
(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.
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?
(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).
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.
(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.
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.
(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.
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
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.
(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"?
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.
(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".
How so?
(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?
"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.
I'll escalate to a tracker issue.
Escalated to http://www.w3.org/html/wg/tracker/issues/86.