Re: On XPointer and the context-independence of URIs

On Sun, 2002-07-21 at 12:24, Bjoern Hoehrmann wrote:
> * Dan Connolly wrote:
> >> That is, an XPointer of this form:
> >> 
> >>   <x:p>
> >>     <x:a href="#xpointer(//x:div[3])">the third div</x:a>
> >>   </x:p>
> >> 
> >> was deemed inappropriate because it relied on in-scope namespace
> >> declarations to determine the fully qualified name of x:div.
> >> 
> >> The "correct" XPointer by this reasoning is:
> >> 
> >>   <x:p>
> >>     <x:a href="#xmlns(x=http://www.w3.org/1999/xhtml)
> >>                 xpointer(//x:div[3])">the third div</x:a>
> >>   </x:p>
> 
> This is a rather bad example, XPointer currently cannot be used in
> combination with XHTML documents (see RFC 3236) (well, ok, you cannot
> even use them with XML documents until RFC 3023 gets updated) and you
> cannot use xsd:anyURIs in XHTML documents, i.e., the white space
> characters (space and line feed) are illegal and even for xsd:anyURIs
> their use is strongly discouraged.

(no comment on that bit; I'd have to play language-laywer a whole
lot to figure out how much of that I agree with)

> >> [...]
> >> so I don't see how context-independence by itself is an unassailable
> >> argument for requiring xmlns().
> >
> >Right, that's not the whole argument. The point is: the
> >base URI context dependency is known to everything that
> >knows about URI references. You can't introduce more
> >context without teaching all the URI software...
> >which is pretty much impossible.
> 
> What's the difference between both examples for software that does not
> support XPointer?

None. But keep in mind that it's pretty difficult to be sure
the consumer of a URI is never going to interact with an XPointer
implementation. I might copy that URI out of one document,
using a clipboard technology that has no clue about URIs
at all, let alone XPointer; then I might write it in a file,
copy the file, tar/zip it, mail it around the world, untar/unzip
it, grab the reference back out of the file, and stick
it in a user agent that groks XPointers.


> And why is the difference not an argument against
> xml:base?

It is an argument against xml:base.
Well, it's analagous to an argument against deploying
xml:base after deploying XML 1.0; deployment
of xml:base is tricky... it kinda assumes
that anybody who built something that consumes
XML and URI references pays enough attention
to W3C specs to update their software... or
it relies on document authors being savvy enough
to realize which XML vocabularies they can
'mix' xml:base with and which ones they can't.
(The latter is the official story).

It's certainly an argument to roll xml:base
into any future XML specifications.

But at least the scope of xml:base is limited to things
that grok XML; the xml:base specification doesn't
affect things like PDF browers. Or does it... some
of the failure modes are similar (i.e. if a PDF
browser is presented with a reference that got
mangled because somebody failed to take xml:base
into account, the failure looks a lot like
the situation where somebody presented a reference
that was mangled because somebody forgot
to take the namespace context of an
XPointer into account.)

The XPointer case is worse because, except for
same-document references, you can't even tell
if XML is going to be the relevant media type
by the time you go to dereference the
fragment part of the reference.
[I should give an example, but other obligations
take priority just now; sorry... gotta go...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you in Montreal in August at Extreme Markup 2002?

Received on Thursday, 25 July 2002 19:08:22 UTC