- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 11 Mar 2004 14:13:55 -0500
- To: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>, "Svensson, Lars" <svensson@dbf.ddb.de>
- Cc: uri@w3.org
Summary: Earlier, I argued against requiring #fragment processing to be scheme-independent. In principle, I still see only weak arguments for such a rule. On the other hand, the examples that Lars brought forth can be handled as well or better by /pathSegment or ?field=value syntax, IMHO. So as of the moment I don't see any actual harm from leaving the restriction in the specification. It would appear we don't have standing to challenge this interpretation, which I agree with Larry is the predominant interpretation of the prior-RFC language. So I can live with the restriction, even if I don't feel it is the highest and best version of this specification to agree on. I don't see sufficient reason to oppose a claim of 'rough consensus' on this point. Details inline below. At 1:41 PM -0800 2/29/04, Larry Masinter wrote: >The RFC 2396 definition for fragments allows URI implementations >to assume that the URI can be separated from its fragment, >the URI handed off to a separate URI access mechanism, and >the fragment applied after the results have been accessed, >without reference to the scheme or any of the other components >of the URI. > >This is a reasonable assumption, works well for schemes that >have associated GET semantics, including "file", "ftp", >"http", "data", "cid" and many others. > >Allowing schemes to define scheme-specific fragment interpretations >would be a mistake. > >> Might it be impertinent to suggest that these document represent a legacy >> view on the function of fragment identifiers in URIs? > >The document in question is attempting to move from "DRAFT STANDARD" >to "STANDARD", and a legacy view is appropriate. Legacy view is appropriate as regards not conflicting with actual practice. Should not break implementations in use in the field. If the scheme-specific processing of new schemes were performed by existing implementations, then it would make sense to constrain new schemes to follow the past practice. But the fact that this sort of implementation is convenient for existing GET-oriented schemes does not imply that this is a general principle meriting extending over new schemes. I don't see why it would be a mistake, or why this is important, to require that #fragment processing be scheme-unaware. That is an optimization, an effort-reducing measure; not an integrity-of-naming assurance feature. It should be fair game to go on the tradeoff table when coining new schemes. ON the other hand, I don't see that the 'info' examples shown to date demonstrate that the 'info' scheme has standing to challenge this established convention. Considering the example discussed in: http://lists.w3.org/Archives/Public/uri/2004Mar/0001.html The example cited, where it is admitted that a given translation goes into more detail (adds new information) as compared with the original version, is a stunning example of where neither "same" nor "different" is reliably stated with regard to the designees of the two indications. So for the vatican derived/translated version, the URI proposed as info:example/qwerty#vatican could be equally appropriately be indicated by info:example/qwerty/vatican and better be indicated by info:example/qwerty?variant=vatican There is no room in this example for an info-scheme-imposed boolean dividing line saying when readers of the URI should treat the vatican localisation as 'same' as the original and when they should treat them as 'different.' This depends too much on the context of use. It could be conditioned by the context of reference but is not generic across all uses of the two URIs. The URIs in best practice provide names for the distinguished variants where distinguished names are sometimes required, and may or may not provide names for equivalence classes of these where equivalence is sometimes the correct interpretation. The actual nature of the relationship between the derived version and the source of the derived version will need to be communicated outside the URI, as the web of these relationships is a full graph and the best we can do in terms of providing a small graph (in the URI syntax) is a) invoking a registered schema after the manner already supported in the 'info' scheme and b) restricting along concurrent aspects by the selectors in a query part. So the best we can do is to localize to a point in a cited namespace and qualify with first-order properties of that point. The degree of correspondence between the vatican translation and its source should be communicated out-of-band from the URI, the URI syntax lacks the expressivity and the URI body of practice lacks (in fact disavows) that level of connotation. Al > >Larry
Received on Thursday, 11 March 2004 14:16:06 UTC