ACTION-443 Chase down what specs say regarding looking up fragid in 2nd representation if not found in 1st representation

The only generic primary documentation I found that might apply to the
interaction between conneg and fragids was what is found in RFC 3986
section 3.5, which I quote for your convenience (I'm sure most TAG
members have been here many times):

<quote>
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations.
[...]
The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the
primary resource. The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced. If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained. Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications.
</quote>

None of the MIME RFCs (2045-2048) seem to address fragments at all.

The situation is discussed in AWWW section
http://www.w3.org/TR/webarch/#frag-coneg , which pretty much agrees
with my reading of 3986: combine all the semantics you can extract
from all the "representations" you can get your hands on, pray that
the combination is consistent, and form your ideas about the secondary
resource from the combination.

In AWWW there is some ambiguity around the word "consistent" and a
potential power struggle between
  (AWWW) The representation provider decides when definitions of
fragment identifier semantics are are sufficiently consistent.
  (3986) The fragment's format [is] dependent on the media type
What the media type registration says is certain to impact
"consistency" among definitions (as we have seen with xml vs. rdf+xml)
- so if the server and the media type registration disagree, who wins?
I'd say the media type, since it's the client, who has no way to read
the server's mind, will pay the price. I don't think "The
representation provider decides" was meant to imply authority, was it?
Just responsibility, as in "has to decide"?

To me this story is an unfortunate failure of nose-following. Even if
only one "representation" provides the information that's needed, a
client still has no way ahead of time to know what media type to ask
for in order to get that "representation". They might try 100
different media types and give up, when the information they wanted
was in the 101st... But I'm happy to assume this is not of major
practical importance, and let anyone affected sort this out for
themselves.

Jonathan

Received on Monday, 12 July 2010 19:22:50 UTC