Re: rel:foo for those who can't do without 'relative' URIs

Tim Berners-Lee wrote:

> >For those times when you just can't do without a relative URI reference,
> may
> >I suggest the "rel" scheme be defined e.g.
> >
> >xmlns:a="foo" --> xmlns:a="rel:foo"
> >
> >when attempting to dereference the rel URI, the scheme is defined to
prefix
> >the base URI, thus the rel: scheme provides the exact same semantics as
the
> >relative URI reference yet is a legal absolute URI.
>
>
> No, sorry, you can't do that.  A URI cannot be document-relative.
> (True there are some schemes like file: which only work within one machine
> but the intent is clear that the space is provided in order to include
> filenames
> which have that property, on systems which will only encompass one
machine).

    But Microsoft's xmlns="x-schema:../schema-element" does *exactly* this!

    Why are you creating an arbitrary distinction of what is allowable
within a file vs. what is within a fileserver?

>
> People are doing string comparison of URIs all over the place.
> You would be moving the problem we have with relative URI referencess into
> the Absolute URI domain!

    There are already many many 'absolute' URI schemes (including practical
http:) which already have significant context dependencies e.g. cookies

    You can technically call a URI absolute, but it doesn't eliminate
context dependent information being used when binding to the data when the
URI is resolved. The 'absolute' URI "rel:../../foo" just happens to depend
on path context within a document as opposed to within a file namespace.
There is really no conceptual difference between the two except that one
points to a document node and the other points to an element node.

    You are depending on a syntactic solution to solve a semantic problem.
All I am saying is that the syntax should be consistent and that most of the
essence of a document ... read infoset ... ought depend on the contents of
the file rather than the location of the file containing the document.
Agreed, the baseURI will change but the very *existence* of an infoset ought
not depend on where the file is physically located.

    Unfortunately if relative namespaces are absolutized, the very existence
of the infoset may change. This is a deep problem (IMHO).

>
> >with this in place, is there *any* reason (besides the 3 legacy documents
> >:-) not to ban relative URI references as namespace names?
>
>
> That may still be the consensus.
>

    This seems to be the only agreeable option.

Jonathan

Received on Thursday, 8 June 2000 18:21:25 UTC