Re: Rehash of literal-vs-relative argument status

John Cowan <jcowan@reutershealth.com> wrote:
>"David G. Durand" wrote:
>  > Deprecating, and perhaps forbidding them
>>  is the best way around the the _lack of agreement_ on this
>  > fundamental issue.
>
>Deprecating them does not help me, because I must define the (superficial)
>semantics of even deprecated constructs in the Infoset.

String identity should be used in the infoset, as that is what the 
recommendation defines. Some namespace identifiers just are not legal 
URIs, and that's why they're deprecated.

>  > I also argue that we have seen that even developers are a bit fuzzy
>>  about the details of the definition of the absolutize function, and
>>  that it produces counter-intuitive results for URI references that
>  > have more leading ../'s than the base URI has path components.

Right, but in this case, the result is undefined. That's 
counter-intuitive since people believe that relative URI resolution 
is defined for all inputs. Furthermore, the standard allows a 
conforming application to recover from this error, in an undefined 
way. It's not clear to me if the clause gives an exhaustive list of 
(incompatible) ways to recover, or just an exemplary list to spark 
developers' creativity.


>Not counterintuitive, just erroneous.  RFC 2396 5.2.7.g:
>
>#      g) If the resulting buffer string still begins with one or more
>#         complete path segments of "..", then the reference is
>#         considered to be in error.  Implementations may handle this
>#         error by retaining these components in the resolved path (i.e.,
>#         treating them as part of the final URI), by removing them from
>#         the resolved path (i.e., discarding relative levels above the
>#         root), or by avoiding traversal of the reference.
>


   -- David
-- 
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
http://cs-people.bu.edu//dgd/             \  Chief Technical Officer
     Graduate Student no more!              \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
                                              \__________________________

Received on Tuesday, 20 June 2000 14:17:04 UTC