Re: Fragid semantics and language conneg

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