- From: Dan Brickley <danbri@danbri.org>
- Date: Wed, 06 Sep 2006 22:59:23 +0100
- To: Dan Connolly <connolly@w3.org>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, simonstl@simonstl.com, noah_mendelsohn@us.ibm.com, Bjoern Hoehrmann <derhoermi@gmx.net>, www-tag@w3.org, www-xml-linking-comments@w3.org, Jonathan Marsh <jmarsh@microsoft.com>
Dan Connolly wrote: > On Wed, 2006-09-06 at 15:47 -0400, Booth, David (HP Software - Boston) > wrote: >>> From: Dan Connolly [mailto:connolly@w3.org] > On balance, I still find # URIs a lot more straightforward than > redirects. I was wondering how to make these kinds of #-/ disputes more measurable. (I didn't succeed...). How many media type specifications actually define a semantics for what # "views" mean and/or refer to? How many of them note that, for any given piece of content that's to be published in the Web, it shouldn't be deployed in a way that #something is given different meanings by any of its published content types. If the PNG spec and the GIF spec and the JPEG specs disagree on what #blah means, I should avoid making an image available content-negotiated in those formats. It isnt just a matter of my own self-discipline in not using "myimage#blah" URIs, ... since the very fact that myimage is available in GIF, PNG, JPEG or whatever invites folk to read those file format specs, and ... figure out what #blah means for content of that type. If most media types don't bother saying anything precise about #blah, I guess it's not a big problem for content negotiation. But right now there seems a big question mark about what kinds of document it is reasonable to put into a content-negotiated bundle: can I sensibly do this with PDFs and Open Office docs, for example? How would I find out? For the restricted case of RDF docs, ... I can see that # might win out. But I'm still left with a big sense of 'uhoh' re use of # identifiers, because of the many other media types who don't say anything very precise about it. Dan
Received on Wednesday, 6 September 2006 21:57:35 UTC