[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
> Therefore, http://www.example.com/data/test.xml and yes. Is there some
> other part of the spec that raised this question? The "last segment is
> removed" part?
3986 is normative now and has replaced 2396. However both the algorithms
in 2396 and 3986 seem to indicate that the result is
http://www.example.com/data/limit/test.xml, not
http://www.example.com/data/test.xml. I'm not sure if:
A. I'm misreading the algorithm
B. This is a bug in the algorithm
C. This is an often unrecognized consequence of the specification
The problem is that both 2396 and 3986 remove the segment following the
last slash *before* removing dot segments. Thus
http://www.example.com/data/limit/.. and
http://www.example.com/data/limit/../ do not get treated the same.
The point about servers automatically appending a / at the end is a good
one. However in the case I've constructed with xml:base, I don't think
this applies.
Hmm, perhaps there is a way out of this. If removal of dot segments were
applied to *all* URIS, not just at the resolution step, then we could
say that the base URI of <parent
xml:base="http://www.example.com/data/limit/.."/> was actually
http://www.example.com/data/, not http://www.example.com/data/limit/..
In this case the relative resolution works as we expect. However, I can
find no justification for that leap in XML Base, XML Infoset, or RFC 3986.
This would affect other URIs as well. For instance, what is the base URI of
<foo xml:base="http://www.example.com/test/.././data.xml"; /> ? Is it
http://www.example.com/test/.././data.xml or
http://www.example.com/data.xml? This one may be academic, but in the
case I originally proposed, you could actually end up linking
to/including/loading a different document depending on how you handle this.
--
Elliotte Rusty Harold elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
|
