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

validating vs. non-validating

From: Rob Cameron <cameron@cs.sfu.ca>
Date: Fri, 30 May 2003 15:59:43 -0700
To: uri@w3c.org
Message-Id: <200305301559.43121.cameron@cs.sfu.ca>

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

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

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