- From: David Booth <david@dbooth.org>
- Date: Wed, 03 Nov 2010 14:21:31 -0400
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: www-tag@w3.org
On Mon, 2010-11-01 at 13:28 +0000, Jonathan Rees wrote: > Section 3.2.2 of AWWW says that inconsistent fragid semantics is a > server error. > > representation providers must not use content negotiation to serve > representation formats that have inconsistent fragment identifier > semantics > > This is in the context of a discussion of representations having > different media types, but the rule would also apply in the case where > there is only one media type involved, say text/html. RFC 2854 says: > > For documents labeled as text/html, the fragment identifier > designates the correspondingly named element; any element may be > named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and > MAP elements may be named with a "name" attribute. > > If one text/html representation gives one element, and a different > text/html representation gives a different element (perhaps in a > different language, or, as in the memento protocol, from a different > time), As a partially related comment, in considering the time dimension I think two cases should be considered separately: 1. A URI identifies a resource whose representations are intended to vary over time, such as the current weather report for Oaxaca. In this case, I think it makes sense to view the URI as identifying a single logical resource that provides different representations at different times. 2. URIs that are reassigned for different purposes, such as when a domain name is sold and reused, or a web site is reorganized, and completely unrelated content is served from the same URI. In this case, I think it makes more sense to view the URI has having been re-bound to a different resource, since that's really what happened. > that sounds like an inconsistency to me - e.g. the two elements > might be of different types, or have different content, and a single > element cannot have two types, or more than one content. > > Of course there is no problem here *in practice*. The fragid is doing > exactly what it's supposed to do - it's getting viewers to the right > part of the document, in the language of their choice. We just don't > have a theory that explains this. > > The media types talk about what the fragid designates *according to > that representation*. AWWW (and RFC 3986) wants to talk about what the > uriref "identifies", independent of (but consistent with) all > representations. Maybe media type "designation" has to be > representation-relative, and different from "identification", which is > not. Or maybe "designation" is not connected with "semantics" (ugh). > Or else "designation" inconsistencies are fine, but lead to situations > where urirefs don't "identify" anything in particular. > > If we have representation-relativity among representations for one > media type, why not relativity between representations having > different media types, or even within a single representation (per our > discussion of application/rdf+xml)? What consistency condition, if > any, is the most useful one? > > I can't get too worked up about this but I don't like muddles. It > would be nice to have a straight story before issuing opinions on > things like 3023bis and fragids in redirects... can anyone think of a > fix? Looks to me - just off the cuff mind you - like the most > parsimonious fix is to say that fragids "identify" information > resources, abstracted over representation, I agree. IOW I think it makes sense to say that the URI with the fragID identifies a single (logical) resource, which may have different representations. David > with "representations" > defined in most cases according to the fragid sections of media type > specs - that is, reduce it to the previously unsolved problem "what is > an information resource". E.g. if GET http://example.com/doc yields a > representation with fragid aa "designating" an HTML element <ee/>, > then element <ee/> is a "representation" of the secondary resource > http://example.com/doc#aa . > > Jonathan > > > -- David Booth, Ph.D. Cleveland Clinic (contractor) http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Received on Wednesday, 3 November 2010 18:22:01 UTC