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

Jonathan,

Interesting work. I did something related in the Media Fragments WG a year
ago [1] and [2] which sort of confirms your finding re:

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

/me just wondering where you have "MIME RFCs (2045-2048)" from ... did I
miss anything?
 
Cheers,
      Michael

[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/Semantics
[2] http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Jonathan Rees <jar@creativecommons.org>
> Date: Mon, 12 Jul 2010 15:22:17 -0400
> To: <www-tag@w3.org>
> Subject: ACTION-443 Chase down what specs say regarding looking up fragid in
> 2nd representation if not found in 1st representation
> Resent-From: <www-tag@w3.org>
> Resent-Date: Mon, 12 Jul 2010 19:22:51 +0000
> 
> 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 Tuesday, 13 July 2010 06:37:51 UTC