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

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:

http://example.com/resource/1#body;about

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:

http://example.com/resource/1;about

and if you want to retain the fragment:

{uri};about#{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...

EHL


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