W3C home > Mailing lists > Public > uri@w3.org > June 2003

Re: validating vs. non-validating

From: Roy T. Fielding <fielding@apache.org>
Date: Tue, 3 Jun 2003 18:45:13 -0700
Cc: uri@w3c.org
To: Rob Cameron <cameron@cs.sfu.ca>
Message-Id: <2F04F3A4-962E-11D7-BA03-000393753936@apache.org>

> Read literally, the spec could be interpreted to mean that
> a new implementation of a nonvalidating parser should
> actually produce "backwards-compatible" behaviour.

Yes, that was a poor choice of words.  What I wanted to say was
that an application testing for invalid links should consider
those references to be invalid because their interpretation will
be inconsistent.

> I'm wondering whether the intent is really to suggest
> that the behaviour that produces "http://a/b/c/g" is
> deprecated, but that implementors should be aware of this
> behaviour in older implementations.

A little more than that.  Some browser implementations have
insisted that this behavior is necessary for backward compatibility,
even though it has a negative impact on parsing non-hierarchical
schemes.  However, I've managed to tweak the algorithm for abnormal
reference parsing to fix that, so maybe we should just restore
the deprecated behavior.

For now, I have changed it to "strict" instead of "validating".

> I was also trying to track down the genesis of this behaviour
> in RFC 1630, but find only that in "the context of URI
> magic://a/b/c//d/e/f" g:h expands as g:h.  Is there arother
> reference?

Where 1630 says:

    The rules for the use of a partial name relative to the URI of the
    context are:

       If the scheme parts are different, the whole absolute URI must
       be given.  Otherwise, the scheme is omitted, and:

many implementations (including CERN/W3C libwww) interpreted that
as meaning the scheme parts are ignored if they are the same.

> Perhaps the algorithm of section 5.2 could be simplified,
> leaving the caveat on deprecated behaviour as a footnote.

The algorithm doesn't change much either way.  What changes is
the number of applications that are compliant to the standard.

Received on Tuesday, 3 June 2003 21:42:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC