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