* James M Snell <[EMAIL PROTECTED]> [2005-08-04 21:15]:
> Personally, however, I think that the elegance and simplicity
> of in-reply-to and replies link rel values trumps defining them
> as elements in a separate namespace or an otherwise perfectly
> engineered solution. As for specifying the source of the
> resource being replied to, a namespace extension inside the
> link element is probably the best way to go.
I consider it stupid blunder to have proposed using atom:link for
this, not elegant and simple.
You need a link and an extension element either way.
So choose to squirrel away information that even clients without
threading support could use inside a namespaced element, and
instead put information they have no use for in a place they can
access. What a mess.
Why not do it the other way around?
> Using the via link just seems unnatural to this purpose in that
> we're not expressing a relationship like "The information
> contained here-in was received through..." we're expressig "The
> information contained here-in is a response to...". Via works
> great for the former and doesn't fit for the latter.
So just drop back to “related.” Either way the exposed
information is sensibly usable even by clients without threading
support; they don’t know *why* it’s related, but it certainly is
useful to let them partake of that information.
> All of the examples that have been offered built around the via
> mechanism just seem entirely too verbose for comfort...
Verbose, sure. Too verbose, how?
> especially given that we're trying to optimize for optional
> metadata that hints at a relationship that can't be reliably
> confirmed (e.g. that the entity being replied to MAY exist at
> the specified source).
You are going to need a namespace any way you turn it. If you
really don’t care about exposing as much information as they can
use to as many clients as possible, and brevity is such a
concern, then maybe it should be
<thr:in-reply-to src="http://example.com/atom";>urn:foo:1</thr:in-reply-to>
which makes this a Structured instead of a Simple Extension
Element, but then maybe that was unavoidable anyway.
Of course, conscientous producers will drop in a
<link rel="related" href="http://example.com/atom"; />
for good measure, so it’s verbose anyway.
Hmm.
Huh.
Interesting.
I like this even better than my previous proposition.
D’oh. Screw sticking to Simple Extension Elements, this is
better. This is *natural* – no funny business with markup inside
atom:link elements. Each piece of information is available to as
broad an audience as possible: threading-aware clients can
correlate the “related” links to the source attributes, and
non-aware clients can at least tell there is something related at
the indicated resource.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
