W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

RE: Request for feedback: HTTP-based Resource Descriptor Discovery

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Wed, 4 Feb 2009 09:38:52 -0700
To: Phil Archer <phil@philarcher.org>
CC: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>, Mark Nottingham <mnot@mnot.net>, "www-talk@w3.org" <www-talk@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939ACF@P3PW5EX1MB01.EX1.SECURESERVER.NET>

My understanding of the point Jonathan made is that it was specifically targeting the template vocabulary. For example, consider the following resource URI and template:

Resource: http://example.com/resource/1#body
Template: {uri};about

The question is, does {uri} includes the #body fragment or not. If it does, the template produces:


which is wrong as it places the suffix in the fragment. My solution in the upcoming draft (-02) is to exclude the fragment and '#' from the {uri} variable. So the above example will produce:


and if you want to retain the fragment:


The other option is to define two sets of {uri} variables, but that seems too messy and is not called for in most use cases.

But none of this implies anything with regards to using fragments in links...


> -----Original Message-----
> From: Phil Archer [mailto:phil@philarcher.org]
> Sent: Wednesday, February 04, 2009 1:42 AM
> To: Eran Hammer-Lahav
> Cc: Jonathan Rees; www-tag@w3.org; Mark Nottingham; www-talk@w3.org
> Subject: Re: Request for feedback: HTTP-based Resource Descriptor
> Discovery
> Eran, Jonathan,
> I've been catching up with this thread this morning. The discussion
> around redirects shows that it's not a simple matter. In POWDER we
> basically chickened out and said that how redirects are handled is
> application-specific. We get away with this because what a POWDER DR
> describes is defined within the POWDER doc, and who published it is
> always explicit. Therefore whether you follow an Link: on a 301
> response
> is irrelevant, the data you eventually get, however you get it, is
> self-contained.
> However, the particular line that caught my eye in this thread was:
> [..]
> [JR]
> >> - I think you need to warn that this protocol should only be applied
> >>    to URIs not containing a fragment id.  If you allow fragment ids
> >>    you're going to get into serious problems with both quoting and
> >>    semantics.
> [EHL]
> > I am not sure what to do here. Should the fragment be removed from
> the definition of 'uri' in the template vocabulary? That seems like the
> easiest solution (allowing it to be used explicitly with the 'fragment'
> variable).
> >
> >
> OK this would be a big problem for POWDER where we make specific use of
> fragment IDs. The basis of POWDER is that you apply descriptors to
> things defined by string or reg ex matches against a URI (everything on
> example.com, all its subdomains etc.). But content management systems
> don't always arrange things nicely so that the pattern matching can
> work. Our big use case (and WG member) Deutsche Telekom (t-online.de)
> being a case in point (at least for the time being they use numeric
> URIs
> with no discernible pattern).
> In those situations we need to link from a resource directly to its DR
> directly which we do using fragment IDs. So you create a POWDER file,
> complete with attribution and a restriction on its applicability to,
> say, t-online.de, and then put an xml:id on a actual descriptor set. A
> resource can then link to that descriptor set with
> <link rel="describedby" href="/powder.xml#red"
> type="application/powder+xml" />
> (or its HTP equivalent). Note the #red frag. It's not as powerful as
> the
> primary POWDER method of resource grouping but it is something we need
> to support so please, please don't say that a describedby link can't
> have a fragment ID!
> Chapter and verse on this is at [1]
> Phil.
> [1]
> http://www.w3.org/2007/powder/Group/powder-dr/20090120-
> diff.html#directDescript
Received on Wednesday, 4 February 2009 16:39:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:27 UTC