W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2008

Re: /site-meta Support for URI-mapped Links

From: Alphonse Tan <alphonse.tan@gmail.com>
Date: Sun, 30 Nov 2008 09:56:47 +0800
Message-ID: <209322380811291756w396b1cd9v9060ef3f906c5bfe@mail.gmail.com>
To: www-talk@w3.org

Gud day to you, i am just a self-learned web designer/web developer. i've
been up to my neck studying and trying to fit in w3 standards. But i can't
seem to catch up.

Question is where do i get, aside from w3.org(sorry guys), get some
standards just like what you outlined, readable in plain english. Not that I
am slow to understand, just that plain english guidelines more or less takes
out the chances of me thinking of something else..

Thanks and more power.


On Sun, Nov 30, 2008 at 9:36 AM, Eran Hammer-Lahav <hueniverse@gmail.com>wrote:

> A Bit of Background
> My involvement in the /site-meta proposal came directly out of my work on
> web discovery [1]. This goal is to provide a uniform and easily
> implementable method for locating resource descriptors.
> With the development of interoperability specifications comes the need to
> enable compliant services and resources to declare their conformance to
> these specifications. There is a growing need to describe resources in a
> way
> that does not depend on their internal structure (i.e. HTML, ATOM, XML,
> etc.) or even the availability of an HTTP-accessible representation of
> these
> resources served by an HTTP server).
> XRDS/XRD and POWDER are two descriptor formats, and OAuth, OpenID,
> OpenSocial, PortableContacts are some specifications with such discovery
> needs.
> ---
> After a long review [1] of the available methods for attaching descriptors
> to resources, three methods were identified as part of the solution:
> 1. <Link> Element in HTML, XHTML, ATOM, and other XML-based schemas with
> support for an equivalent element. Solves HTML/ATOM regardless of transport
> (which is still likely to be HTTP).
> 2. HTTP Link response-header [2]. Solves HTTP URIs with an HTTP
> representation available (if the resource is not HTTP-resolvable, it
> doesn't
> matter that the URI uses the HTTP scheme - there is no place to put the
> header).
> 3. Template-based mapping from the resource URI to the descriptor URI.
> Applicable to any URI scheme - basically the catch-all solution.
> In order to implement the URI-mapping method, we need to define (1) a
> vocabulary to deconstruct the resource URI, (2) a template format to
> construct the descriptor URI, (3) a filtering method to apply templates to
> specific URI schemes, and (4) a place to store these maps.
> Main Questions
> 1. Is /site-meta the correct location for storing such maps?
> * The main reason for the existence of these maps is that they describe the
> location (links) of resources without access to HTTP header (404 or
> non-http
> URIs), or where performance prohibit the inclusion of Link headers
> (http://yahoo.com<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fyahoo.com>,
> http://google.com<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fgoogle.com>
> ).
> * The maps define a site-wide link which is applied at an individual
> resource level, but is clearly related to the 'web site' as a whole.
> * The map can be viewed as a Link relationship where the 'href' attribute
> is
> replaced with a 'template' attribute which is used to constructed a Link
> for
> any given URI within that authority space (which is described by the
> /site-meta document).
> * If /site-meta is note the right place, it calls for /site-meta to link to
> another document which will include these maps. This of course require the
> definition of a new rel type and a new content type for the document
> listing
> the maps.
> * DNS has been suggested as an alternative location. A DNS approach suffers
> mainly form complexity and security (lack of DNS-SEC deployment).
> 2. If /site-meta is simplified to a text format with a list of Link headers
> (without the 'Link: ' prefix), how can such URI maps be included?
> * The original (unpublished) proposal included a new XML element next to
> <meta> called <resource-map> which will replace the 'href' attribute with
> 'template' attribute where the map is stored.
> * With the new proposed format [3] for /site-meta, there is no longer an
> 'href' attribute. Instead, the linked URI is listed as the first record in
> each line. Since there is not URI defined for maps, it is not clear how the
> new format can accommodate this in a clean way (start with a space? Include
> only key="value"; pairs?).
> 3. How rich should the common vocabulary for deconstructing and
> reconstructing the resource URI into the descriptor URI be?
> * The simplest proposal includes a single 'uri' variable which can be used
> in a template with a prefix/suffix combination:
>     http://meta.example.net?resource={uri}<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fmeta.example.net%3fresource%3d%7buri%7d>
> * A richer proposal includes 'uri' and all the terms listed in RFC 3986
> [4]:
>          foo://example.com:8042/over/there?name=ferret#nose
>          \_/   \______________/\_________/ \_________/ \__/
>           |           |            |            |        |
>        scheme     authority       path        query   fragment
> where authority can be further broken down into 'domain' and 'port'.
> * An even richer approach includes custom support for mailto URIs:
>     scheme:user@domain
> * Going nuts can include breaking the query into a list of key/value pairs,
> breaking the path into a list of path components ('/' separated), etc.
> There
> seems to be agreement that this is going too far.
> 4. Which URI Templates format to use?
> * Current IETF I-D draft [5] for URI templates has expired with very little
> community support or indication of changes from the authors.
> * A simpler (but still complex) straw man proposal [6] was posted to the
> list by R. Fielding but has not been submitted as a draft at this point.
> * For the majority of use cases using the above vocabulary (list variables
> excluded - i.e. No going nuts), all that is needed is a simple variable
> substitution mechanism (using {}) and some way to indicate whether a
> variable should or should not be percent encoded. A simple format can look
> like this:
>     Resource URI: http://example.com/resource<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fexample.com%2fresource>
>     Template: http://meta.{domain}/map?{%uri}<https://mail.ex1.secureserver.net/owa/UrlBlockedError.aspx>
>     Descriptor URI:
> http://meta.example.com/map?http%3A%2F%2Fexample.net%2Fresource<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fmeta.example.com%2fmap%3fhttp%253A%252F%252Fexample.net%252Fresource>
> Variables prefixed with '%' are percent-encoded before inserted into the
> template. The other proposals posted defines that all variables are percent
> encoded by default and left unchanged if prefixed by '+'. There is no real
> difference between the two approached.
> * An even simpler (but ugly) approach to the above example is define an
> encoded and unecoded variable for each term (i.e. 'uri' and 'encoded-uri').
> 5. To what level should the map be filtered or assigned to a subset of URIs
> under the same authority?
> * There are generally two kinds of filters that can be applied to URI maps.
> One is based on the URI scheme and is required for proper support for
> mapping both http and mailto URIs (an important use-case in the identity
> world, such as OpenID). This is due to the different vocabulary used for
> each scheme.
> * The other filter is based on the value of the path and potentially query
> parts. This seems as an overkill for the currently known use-cases. The
> assumption is that if there is such a need to provide descriptors to such
> complex use cases, these resources should either be separated into sub
> domains (each with a separate /site-meta document), or all maps should use
> just the 'uri' variable and use a CGI script to redirect to the proper
> descriptor.
> Proposal
> Include direct support for URI-maps in /site-meta. Use a Link record
> without
> the URI (basically a record with only key="value"; pairs) with two
> additional parameters: 'template' (to hold the URI template) and 'scheme'
> (to hold the optional scheme filter).
> The URI template will use a simple {} variable substitution with '+' prefix
> indicating that no percent encoding should be performed. The proposed
> vocabulary includes: uri, scheme, authority, domain, port, path, query,
> fragment, and username (for mailto URIs).
> [1] http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2fwww.hueniverse.com%2fhueniverse%2f2008%2f09%2fdiscovery-and-h.html>
> [2] http://tools.ietf.org/html/draft-nottingham-http-link-header-02<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-nottingham-http-link-header-02>
> [3] http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0002.html<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2flists.w3.org%2fArchives%2fPublic%2fwww-talk%2f2008NovDec%2f0002.html>
> [4] http://tools.ietf.org/html/rfc3986#section-3<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc3986%23section-3>
> [5] http://tools.ietf.org/html/draft-gregorio-uritemplate-03<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-gregorio-uritemplate-03>
> [6] http://lists.w3.org/Archives/Public/uri/2008Sep/0007.html<https://mail.ex1.secureserver.net/owa/redir.aspx?C=cc75fe81921d457583420bebbbebfc13&URL=http%3a%2f%2flists.w3.org%2fArchives%2fPublic%2furi%2f2008Sep%2f0007.html>
Received on Sunday, 30 November 2008 07:43:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:07 UTC