scheme-independent #fragment processing [was: RE: fragment prose proposal]

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