* Antone Roundy <[EMAIL PROTECTED]> [2005-07-13 04:20]: > If atom:link is intended to be dereferencable, then clearly, > any solution that takes a value from atom:id and puts it into > atom:link/@href has a strike against it since any feed that > uses non-dereferencable atom:ids would either have to violate > the spirit of atom:link to participate in the feature, or would > have to invent a competing solution.
If atom:link is indeed intended to be dereferencable, then my proposition is bunk and we need an extension element. Even if the atom:id elements in question carried dereferncable URIs, and thus could meaningfully be put into atom:link elements, that is beside the point. The letter of the spec does not mandate dereferancability right now. On whether this is intentional or an oversight, I await judgement from the WG. Obviously, my own vote is that it’s fine as is: I see no reason that dictates that atom:link must point to a concrete Web resource, rather than just an abstract one – neither conceptually/semantically nor in terms of consequences for implementation of Atom generators and consumers. OTOH, if the WG thinks the spec is meant to be stricter than the letter of the current document, that might be a minor spec bug that should be fixed in the -10 draft. (I’m not entirely clear where the minor/major change threshold is at this stage in the process, and if a fix to this aspect would violate it. The wording would only require trivial additions; but the consequences of the change might be considered too major. Unless maybe it’s argued that this was what the spec said all along, and this change therefore is just clarification? I don’t know. Colour me lost.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
