- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 1 Nov 2010 13:28:05 +0000
- To: www-tag@w3.org
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), 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, 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
Received on Monday, 1 November 2010 13:28:36 UTC