Subject: service link rel registration

From: James M Snell <[email-masked]>
Date: Tue, 20 May 2008 13:37:13 -0700

FYI.. the "service" link rel has been added to the IANA registry.

Short version: rel="service" indicates a URI that can be used to
retrieve an Atom Publishing Protocol Service Document as defined
by RFC 5023.

see:

   http://www.iana.org/assignments/link-relations.html
   http://www.iana.org/assignments/link-relations/service

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 21 May 2008 11:08:53 +1000

> retrieve an Atom Publishing Protocol Service Document as defined

Shouldn't @rel be @type agnostic?

e.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 May 2008 08:20:39 +1000

+1 - that was my feedback as well.

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Fri, 23 May 2008 07:38:46 -0700

Ordinarily, yes.  The purpose of the rel="service" link, however, makes 
that difficult.  The whole point of rel="service" is to make it possible 
to discover Atompub Service Documents, for which there is only a single 
media type.

Note, the existing rel="self" is also not @type agnostic.  If rel="self" 
is used in an Atom feed, the @type would rightfully be expected to be 
"application/atom+xml".

- James

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Fri, 23 May 2008 17:50:34 +0200 (CEST)

>
> On 24/5/08 12:38 AM, "James M Snell" <[email-masked]> wrote:
>
> The whole purpose of Atompub Service Documents is to enable a client to
> discover the capabilities and locations of the available collections. It's
> reasonably possible that this information could be made available in
> different formats. The *relationship* to documents describing the
> capabilities and locations of the available collections is the same,
> regardless of whether the format of the document is an Atompub Service
> Document.
>
> e.
>

Although I don't disagree with you Eric, don't you think you have
slightlty too many "if"? There has been no use case that you describe yet
and considering that the service document is hardly publicly displayed it
seems as reasonnable to narrow down to the AtomPub service document.

- Sylvain

-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Eric Scheid <[email-masked]>
Date: Sat, 24 May 2008 01:35:58 +1000

e.

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 23 May 2008 09:14:41 -0700

> regardless of whether the format of the document is an Atompub Service

I agree that other formats are possible (and unlikely to be worse), but I 
don't see the harm in reserving rel='service' for AtomPub service documents. 
If you come up with a better mechanism/format for doing service discovery 
then it would be better to distance it from the application/atomsvc+xml 
document type by using different link relations.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 23 May 2008 09:16:40 -0700

- Brian

---

From: Antone Roundy <[email-masked]>
Date: Fri, 23 May 2008 11:35:43 -0500

Brian Smith wrote:
> I agree that other formats are possible (and unlikely to be worse), but 
> I don't see the harm in reserving rel='service' for AtomPub service 
> documents. If you come up with a better mechanism/format for doing 
> service discovery then it would be better to distance it from the 
> application/atomsvc+xml document type by using different link relations.

"Distancing" future service document formats from 
application/atomsvc+xml documents is link/@type's job, not link/@rel's. 
That's what link/@type is for, and it's perfectly capable of expressing 
the distinction. I see no benefit in, nor any reason to limit the scope 
of the service link relation.

---

From: Paul Denning <[email-masked]>
Date: Fri, 23 May 2008 14:35:26 -0400

>   http://www.iana.org/assignments/link-relations/service

You may have seen
[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-05-12.html#ATOM

In the example above, the short name "enclosure" is used.

I was surprised to get a 404 error on
http://www.iana.org/assignments/relation/enclosure

Likewise,
http://www.iana.org/assignments/relation/service
also results in 404.

RFC 4287 section 4.2.7.2 specifies [2] as a base.
[2] http://www.iana.org/assignments/relation/

Looking at
[3] http://www.iana.org/assignments/link-relations.html

Some of the values for @rel can be resolved using the following base URI
[4] http://www.iana.org/assignments/link-relations/

However, even using this base others give a 404 error.

Is there errata or some other RFC that specifies [4] instead of [2] 
as the base?

A "good practice" stated in [1] is that
"Web representations should link to the information needed to support 
automatic processing of those representations. "

So either the value of @rel is a URI/IRI, or it is a short form with 
a well specified way to construct a URI/IRI.
Given that URI/IRI, it should be resolvable.

Are there any plans to provide a document that can be resolved for 
every @rel value registered with IANA [3]?

I've mentioned some of this to W3C TAG
[5] http://lists.w3.org/Archives/Public/www-tag/2008May/0137.html

Paul

---

From: Eric Scheid <[email-masked]>
Date: Sat, 24 May 2008 11:51:41 +1000

On 24/5/08 1:50 AM, "Sylvain Hellegouarch" <[email-masked]> wrote:

> slightlty too many "if"?

There is only one "if" in my argument - the possibility that the
capabilities and locations of the available collections could be expressed
in formats other than Atompub Service Doc.

> There has been no use case that you describe yet

What do you mean by "is hardly publicly displayed"? Do you mean you would
see @rel='service' and decide not to display that link in a user interface
(unlike other links like @rel='alternate')? Sounds like a reasonable course
of action for service documents, regardless of their content type .. if only
we had some way of indicating "this resource is a service document, doesn't
matter what format it's expressed in" ;-)

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 24 May 2008 11:52:44 +1000

> of the service link relation.

+1

use @type to distinguish format of document, @rel to distinguish role of
document.

e.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 25 May 2008 10:27:43 +1000

That's a circular argument; there's nothing ambiguous about  
rel="service" type="application/atomsvc+xml".

self isn't atom-specific; the fact that it points to an atom document  
when it occurs in an atom feed is a consequence of its semantics.

On 24/05/2008, at 12:38 AM, James M Snell wrote:

> Ordinarily, yes.  The purpose of the rel="service" link, however,  
> makes that difficult.  The whole point of rel="service" is to make  
> it possible to discover Atompub Service Documents, for which there  
> is only a single media type.
>
> Note, the existing rel="self" is also not @type agnostic.  If  
> rel="self" is used in an Atom feed, the @type would rightfully be  
> expected to be "application/atom+xml".
>
> - James
>
> Mark Nottingham wrote:

---

From: "Erling Wegger Linde" <[email-masked]>
Date: Mon, 26 May 2008 19:02:47 +0200

I've subscribed to this list, reading a few posts from time to time,
so I'm not sure if this issue should be discussed elsewhere, but I
can't help commenting on the Atom Service Document.

I've implemented a simple service using Atom Publishing Protocol with
RDF data in the <content> element. What strikes me is that I would
love to describe on the feed level what main concepts my entries
contain. I've used a link with about="", but I'm not sure if that is
enough. However, when glancing at the Atom Service Document I feel
like this is creating WSDL all over again. Why couldn't we make an
Atom feed self-describing using RDF annotations instead? I mean, you
could probably use HTTP OPTIONS to figure out what the service can do.
All you would need is to specify that an Atom Feed is about persons,
blogposts or whatever by referring to some ontology (e.g. FOAF).

Henry Story has already created the AWOL ontology which could be
extended to support the Atom Publishing Protocol (if it already
doesn't?). Why don't use this when you should link to an APP service?
You could just say, here is a link to an APP service containing
persons I know. A client could then use HTTP OPTIONS to figure out if
it is allowed to POST; PUT or DELETE to the service.

Am I totally off here, or what do you think?

Btw. I realize I'm probably not the first one to propose something
like this, but I guess it can't hurt proposing it again. Please tell
me where to discuss this idea further if this isn't the right place :D

Thanks,
- Erling

On Sun, May 25, 2008 at 2:27 AM, Mark Nottingham <[email-masked]> wrote:
>
> That's a circular argument; there's nothing ambiguous about rel="service"
> type="application/atomsvc+xml".
>
> self isn't atom-specific; the fact that it points to an atom document when
> it occurs in an atom feed is a consequence of its semantics.
>
>
>
>> that difficult.  The whole point of rel="service" is to make it possible to
>> discover Atompub Service Documents, for which there is only a single media
>> type.
>>

-- 
Med vennlig hilsen
Erling Wegger Linde

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 27 May 2008 11:36:31 -0400

> use @type to distinguish format of document, @rel to distinguish role of

Well, the media type of the returned representation is what determines
the format, and @type is just an optimization.  But you're right about
@rel: none of its registered values should preclude other formats
being used in the future.

Mark.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 28 May 2008 03:23:52 +1000

On 28/5/08 1:36 AM, "Mark Baker" <[email-masked]> wrote:

> the format, and @type is just an optimization.

Yes, but you'd use the @type to choose between which @href to pull, well
before you ever see the media type of the returned representation.

> But you're right about

are the rel registry policies documented anywhere? should they be?

e.

---

From: Bill de hOra <[email-masked]>
Date: Wed, 28 May 2008 00:08:56 +0100

> when it occurs in an atom feed is a consequence of its semantics.

I doubt 'self' has semantics that allows us to be so specific.

Bill

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 May 2008 15:56:07 +1000

> are the rel registry policies documented anywhere? should they be?

This is under discussion right now, as part of the Link header draft.

When the RFC was published, the registry wasn't Atom-specific;  
however, it was later updated by IANA to refer to Atom. There's debate  
as to whether that was a good thing.

Cheers,