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 09:42:17 UTC