W3C home > Mailing lists > Public > public-webarch-comments@w3.org > July to September 2004

Re: non-authoritative syntaxes for fragment identifiers

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 20 Sep 2004 01:23:27 -0700
Message-Id: <58C93632-0ADE-11D9-8051-000393753936@gbiv.com>
Cc: public-webarch-comments@w3.org
To: Myriam Amielh <myriam.amielh@cisra.canon.com.au>

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, 20 September 2004 08:23:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:33 GMT