Re: non-authoritative syntaxes for fragment identifiers

Hello Roy, Ian, all

Thank you for your clarification.  It makes much more sense for those 
statements to apply to any URI, regardless of fragment.  I agree that it 
is preferable to delete the two sentences from section 3.3.1 [Media 
types and fragment identifier semantics] to remove the confusion.

While we are on the topic of interpreting a fragment identifier, some 
W3C recommendations and working drafts such as SVG and the XPointer use 
scheme names in their fragment identifiers to assist the interpretation 
of the fragment.  For instance, SVG uses 'svgView' (e.g. 
http://www.example/file.svg#svgView(...)) and XPointer uses 'xpointer' 
(e.g. http://www.example/file.svg#xpointer(...)). Has the working group 
considered recommending such practice in AWWW, or do you consider such 
recommendation as encouraging "the interpretation of fragment identifier 
based on a syntactic analysis on part of a URI"?

Best regards
Myriam

Roy T.Fielding wrote:

> On Sep 2, 2004, at 8:31 PM, Myriam Amielh wrote:
>
>> The issue I would like to submit here is the following: Does the use
>> of a non-authoritative fragment identifier syntax make a URI invalid?
>> In relation to this problem, I have two observations for the Last Call
>> on AWWW:
>>
>>  1) Paragraph 4 of clause 3.3[.1] specifies:
>>
>>  As with any URI, use of a fragment identifier component does not
>> imply that a retrieval action will take place. A URI with a fragment
>> identifier may be used to refer to the secondary resource without
>> any implication that the primary resource is accessible or will ever
>> be accessed. One may compare URIs with fragment identifiers without a
>> retrieval action. *Parties that draw conclusions about the 
>> interpretation
>> of a fragment identifier based solely on a syntactic analysis of all
>> or part of a URI do so at their own risk; such interpretations are
>> not authoritative because they are not licensed by specification*.
>
>
> Hmm, that is very awkward.  I believe that sentence and the one before
> it ("One may compare ...") are leftovers from a prior edit and should
> be deleted.  The first two sentences are from rfc2396bis.
>
>> In the last sentence (between **), up to the semi-column, no
>> hypothesis was made whether the fragment syntax is based on an
>> authoritative scheme or not (so for instance, we may very well be
>> talking about the authoritative svg fragment identifier #svgView()).
>> Then, the statement "such interpretations are not authoritative" may
>> apply both to authoritative or non authoritative syntaxes, and that
>> may be confusing.
>>
>>  I wonder whether the intention was more something like:
>>
>> *Parties that draw conclusions about the interpretation of a fragment 
>> identifier based solely on a syntactic analysis of all or part of a
>> URI, *and not on a registered syntax*, do so at their own risk; such
>> interpretations are not authoritative because they are not licensed
>> by specification.*
>
>
> No, that was definitely not the intention.
>
> Even if the syntax is registered for a given media type, there is
> no guarantee that such a media type will be found at that URI.
> Consider, for example, a meta-format that talks about all of the
> secondary resources defined within some other format -- such a
> media type would, by necessity, have to accept all of the fragment
> syntaxes defined by the media types it describes, and thus even a
> "registered" fragment scheme like svgView is not sufficient to
> make assumptions about the secondary resource.
>
>>  2) This clause seems to allow the use of a non-authoritative fragment
>> syntax although there is no guarantee it can always be processed.
>> I think it is reasonable to allow the use of non-authoritative
>> fragment syntaxes, especially considering that:
>>
>>  - although in some cases Internet media types owners may not need/want
>>  to define a syntax, content owners may want to address fragments of
>>  content, and have to define non-authoritative syntaxes,
>>  - in the future, it may be beneficial to establish common conventions
>>  for addressing fragments consistently across multiple representations
>>  of a content. Indeed at the moment, very few Internet media types
>>  have defined a syntax for fragment identifiers.
>>
>>  At the moment, both the RFC2396bis and the AWWW specify that:
>>
>>    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.
>>
>> This does not clearly state whether the use of a non-authoritative
>> scheme is valid or not. Another situation could happen if a
>> non-authoritative fragment syntax is widely used on the web for a
>> particular representation and later on an Internet media type owner
>> registers a fragment syntax. Both schemes could potentially coexist
>> and be deployed assuming that the syntaxes use a mechanism to help
>> the processor identify which scheme applies (for instance using a
>> scheme name as for the Xpointer Framework).
>>
>> If the use of non-authoritative fragment identifier syntaxes in
>> URIs is allowed, although at the user's own risk, such URIs should
>> be valid. Therefore, I suggest that AWWW clarifies whether a URI with
>> non-authoritative fragment identifier is still a valid URI or not.
>
>
> The same paragraph continues with:
>
>    If no such representation exists, then the semantics of the
>    fragment are considered unknown and, effectively, unconstrained.
>    Fragment identifier semantics are orthogonal to URI schemes and
>    thus cannot be redefined by URI scheme specifications.
>
> Logically speaking, if it is possible to have fragments without
> a defining media type, then it must be possible to use
> "non-authoritative" fragment syntaxes.
>
> In any case, I don't believe that the sentences
>
>    One may compare URIs with fragment identifiers without a
>    retrieval action. Parties that draw conclusions about the
>    interpretation of a fragment identifier based solely on a
>    syntactic analysis of all or part of a URI do so at their
>    own risk; such interpretations are not authoritative because
>    they are not licensed by specification.
>
> belong in this part of the document at all.  Those statements
> are supposed to apply to any URI, regardless of fragment, and thus
> duplicate (poorly) what is already said in sections 2.5 of AWWW and
> in rfc2396bis.
>
> If we remove the above two sentences, would that be sufficient to
> remove the confusion and satisfy your comments?  If not, do you
> have a suggested sentence to add that would satisfy them? 

>
>
>
> Cheers,
>
> Roy T. Fielding                            <http://roy.gbiv.com/>
> Chief Scientist, Day Software              <http://www.day.com/>
>
>

Received on Monday, 27 September 2004 23:39:02 UTC