Re: link types

["Seairth Jacobs" <seairth@xxxxxxxxxxx>]

From: "Ken MacLeod" <ken@xxxxxxxxxxxxxxxx>
>
> "Seairth Jacobs" <seairth@xxxxxxxxxxx> writes:
>
> > I am getting lost in what <link> is and isn't for.  So, I figured I
> > would try a different tact.  Suppose we add two attributes: @type
> > and @method.
>
> I'm hoping this tack is a lot simpler:
>
>   <link>  [1]
>     Definition: One of possibly several persistent URI locations for
>     the entry on the Web in the context and style of the publisher's
>     website.
>
>     Comment: Links may change over time.
>
> That's it.  The URI in <link> is what users click on to see the entry
> in the browser.

Except there are (typically) already two versions of the entry:  the Atom
version and the HTML version.  This Atom version is not necessarily the same
as the one you mention below in <editLink>.  Ignoring the possibility of
serving an entry in multiple formats (rss item, pdf, etc), you still have at
least two versions that either need their own URI or need some way to make
conneg a non-issue.  Not ignoring the possibility and as Atom is not
intended to be limited to blogs, I can easily see people wanting to make
"entries" available in a variety of formats to suit their needs.  A single
<link> element just isn't enough.  Maybe drop the @method from my <link> and
leave it with the @type attribute (still working the same way).

>   <editLink>  (proposed)
>     Definition: One of possibly several persistent URI locations where
>     the Atom API can be used to maintain an individual entry.
>
>     Comment: Edit links may change over time.
>
> The Atom API currently describes the use of PUT, GET, and DELETE for
> individual entry/comment URIs, that's what this URI is.  By reference,
> this <editLink> is the same (or equivalent) URI as returned in the
> Location: header after using POST to the createEntry facet in the
> introspection file.

>From what I have seen, people are still hashing out the POST vs. PUT issue.
My attitude is to let the server architect make the choice that suits them
best instead of trying to shoehorn everyone into a single method.  Now,
maybe you could have something like <editLink method="put|post"> (possibly
with "put" being the default, if you want) to resolve that issue.


> Currently, the spec only calls for using Atom <entry> documents at
> this URI, but I like the idea of possibly supporting raw formats as
> well.

As this is the Atom API, I don't have any problem that Atom <entry>
documents would be the only format accessible via the <editLink>.  But
<link> doesn't have to do with the API and shouldn't be "hardwired" as it is
now.

---
Seairth Jacobs (seairth@xxxxxxxxxxx)
Looking: http://www.seairth.com/blog/65