validating vs. non-validating

From section 4.1, I infer that the difference between a validating
and non-validating parser is that the former confirms that the syntax
of individual URI components precisely matches the specified
grammar, while the latter simply breaks the URI into its
components.   This makes sense.

But in section 5.2, the algorithm for resolving a relative
reference seems to suggest that different behaviours are 
required depending on whether "parse" is validating or
nonvalidating.    An example at the end of 5.4.2 also refers 
to this, drawing a distinction between "validating parsers" and 
"backwards compatibility."

   "http:g"        =  "http:g"         ; for validating parsers
                   /  "http://a/b/c/g" ; for backward compatibility

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

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.   

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?

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

Received on Friday, 30 May 2003 18:59:51 UTC