Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

On Mon, Aug 31, 2009 at 3:42 PM, Joe Gregorio <joe@bitworking.org> wrote:

>
> Regardless of who manages the registry, I would like to request that the
>> registration mechanism be made significantly simpler than the one
>> described in the spec.
>>
>
> The registration mechanism calls for creating a document, having it
> discussed, and then
> updating the registry. While that seems like a burden, I'll turn it around
> and point
> out that it gives current active formats the ability to review the meaning
> and request verbiage be added to cover their particular format, such
> as the examples you gave above about document level and phrasing level for
> HTML5.
>

As another real world example of link relations being [ab]used, VMware's
vCloud API<http://communities.vmware.com/community/developer/forums/vcloudapi>(which
is similar to OCCI) was just released as a tech preview today. It
uses link relations in an XML-based DSL, taking advantage of some that
already exist and adding some of its own.

Sure this is their language and they can do what they like, but these
resources could (and will with OCCI) be rendered as Atom, HTML, etc. so
there's definitely some advantage of roping this kind of innovation in
(read: lowering the barriers to entry).

Mark said it well <http://www.mnot.net/blog/2009/04/14/rev_canonical_bad> a
while back:

Stepping back, I think this sort of thing is going to happen more often, not
> less. Microsoft and Netscape unilaterally extended the Web with MARQUEE and
> BLINK, and it was ugly, but the impact wasn’t nearly as bad as countless Web
> developers all extending the Web in their own way could be. The onus is
> clearly upon organisations like the W3C and IETF to make themselves as
> transparent and approachable to developers as possible, so that the latent
> experience and expertise in them can be drawn upon by these innovators,
> instead of being seen as either irrelevant or impediments.
>

Anyway here's a sample from the tech preview:

*About Links and Link Relations *
>
> The vCloud API makes extensive use of links to describe the context for a resource, list other relevant
>
> resources, and define how they relate to the current resource. These links are the primary way that a server
>
> delivers information to a client about how to access and operate on a resource.
>
>
> XML documents returned in response to client requests typically include one or more links of the form:
>
>
> <Link rel="{relationship}" href="{URL}”
> type="application/vnd.vmware.vcloud.{type}+xml" />
>
> where:
>
> The href attribute value is a URL, which should be considered an opaque identifier (one that the client
>
> should not attempt to parse or interpret) that persists for the life of the referenced entity.
>
>
> The type attribute value defines the content type of the request or response body. This attribute is present
>
> only for links that require a body when used to make a request or return one in a response.
>
>
> The rel attribute value defines the relationship of the current resource to the target resource. This
>
> relationship indicates the HTTP request type to use with the href attribute of the link, as shown in
>
>
> Table1‐1:
> These links provide a way for a resource to inform a client about related resources and the operations that are
>
> permitted on them. For example, a container such as an Org or Catalog can return links to the entities it
>
> contains, or an entity such as a vApp can contain links that enable operations such as power state changes or
>
> virtual device reconfiguration.
>
> Table1-1.  Link Relationships and HTTP Request Types
>
> rel Description HTTP Request
> add: Add an item to the current container. POST
> alternate: A link to an alternate representation of the current resource.
> GET
> copy: Copy the current entity into a container specified
> in the request body. POST
> up: A link to the container of the current resource. GET
> down: An item in the current container resource. GET
> edit: Modify the current entity. POST
> move: Move the current entity into a container
> specified in the request body. POST
> remove: Remove the current resource DELETE
> power:powerOn: Powers on the referenced vApp. POST
> power:powerOff: Powers off the referenced vApp. POST
> power:reset: Resets the referenced vApp. POST
> power:suspend: Suspends the referenced vApp. POST
> power:shutdown: Shuts down the referenced vApp. POST
> upload:default: Uploads file data to a default location POST
> task:cancel: Cancels the referenced task. POST
>

Sam