W3C home > Mailing lists > Public > uri@w3.org > July 2004

Re: RFC 2396bis sec. D.2 editorial suggestion (further, still editorial)

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 15 Jul 2004 09:32:36 -0400
Message-Id: <p06110400bd1c35816597@[10.0.1.2]>
To: uri@w3.org

At 9:58 PM -0700 7/14/04, Roy T.Fielding wrote:

>This change may result in additional references being considered
>"same-document" under this specification than would have been the
>case under the rules given in RFC 2396, especially when normalization
>is used to reduce aliases.

The adjective 'additional' is not of the comparative degree. [It is
incremental, not cumulative.] So "additional ... than" is not in line
with standard usage.

So either say

....more references being considered "same-document" ... than would have...

Or say

....additional references being considered "same-document"... that would not
have been considered as such under the rules given in RFC 2396, ...

Al



>On Sunday, May 16, 2004, at 10:45  PM, Mike Brown wrote:
>>In RFC 2396bis draft 05 section D.2 ("Modifications from RFC 2396"), the
>>change to same-document references is currently described like this:
>>
>>   Removed the special-case treatment of same-document references 
>>within the URI
>>   parser in favor of a section that explains when a reference should be
>>   interpreted by a dereferencing engine as a same-document 
>>reference: when the
>>   target URI and base URI, excluding fragments, match. This change does not
>>   modify the behavior of existing same-document references as defined by RFC
>>   2396 (fragment-only references); it merely adds the same-document 
>>distinction
>>   to other references that refer to the base URI and simplifies the interface
>>   between applications and their URI parsers, as is consistent with 
>>the internal
>>   architecture of deployed URI processing implementations.
>>
>>I don't think this is complete or accurate. I suggest changing it as follows:
>>
>>   The determination of whether a URI reference is a same-document
>>   reference has been decoupled from the URI parser, simplifying the
>>   interface between applications and their URI parsers, as is consistent
>>   with the internal architecture of deployed URI processing
>>   implementations. The determination is now based on comparison to the
>>   same base URI that the reference was resolved against, rather than to
>>   the URI of the "current document", which could sometimes differ. Also,
>>   it is now permitted to use URI equivalence, not just identity, to make
>>   the determination. These changes do not modify how references are
>>   resolved to absolute form, but they may affect whether a reference that
>>   was defined same-document by RFC 2396 will be interpreted as
>>   same-document by an RFC 2396bis-based dereferencing engine, and they
>>   may add the same-document distinction to references that would not have
>>   had it before.
>
>I appreciate the reordering of sentences, but most of your description
>is wrong -- it has no such effect on 2396 same-document references
>because those references consisted only of fragment identifiers.
>I have rewritten it as
>
>    The determination of whether a URI reference is a same-document
>    reference has been decoupled from the URI parser, simplifying the
>    URI processing interface within applications in a way consistent
>    with the internal architecture of deployed URI processing
>    implementations. The determination is now based on comparison to
>    the base URI after transforming a reference to absolute form,
>    rather than on the format of the reference itself. This change
>    may result in additional references being considered "same-document"
>    under this specification than would have been the case under the
>    rules given in RFC 2396, especially when normalization is used
>    to reduce aliases.  However, it does not change the status of
>    existing same-document references.
>
>
>Cheers,
>
>Roy T. Fielding                            <http://roy.gbiv.com/>
>Chief Scientist, Day Software              <http://www.day.com/>
Received on Thursday, 15 July 2004 09:48:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT