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
