W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Sep 2009 13:00:46 +1000
Cc: Joe Gregorio <joe@bitworking.org>, Ian Hickson <ian@hixie.ch>, Eran Hammer-Lahav <eran@hueniverse.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <9A21BF5F-03BE-4242-87DB-CD405034F351@mnot.net>
To: Sam Johnston <samj@samj.net>
The easiest way for them to use the link framework would be to use  
extension relations for ones that are specific to their application...  
i.e., not register them.


On 01/09/2009, at 12:57 AM, Sam Johnston wrote:

> 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 (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 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

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 1 September 2009 03:01:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC