Re: A proposed solution

> Hmm so why the reference to
>
> >  A URI space is typically defined with a set of
> > properties concerning uniqueness,
>
> which I read as refering to _absolute_ URI and in particular the uri
> schmeme specific notions of equivalence like
> http://www.w3.org being equivalent to http://WWW.w3.org.

This part states that URIs can encapsulate different URI spaces with
different properties and characteristics. The way you can see what URI
space a URI belongs to is by looking at the scheme component. Nothing
new here.

> I am much relieved to hear that you are not proposing that an
> application would ever take those two strings to denote the same
> namespace.

great

> On relative URI basically you are just chosing the "undefined" option.
> I think? Within a tightly controlled set of applications you may do
> whatever you like, but the real question is what infoset properties
> does a standalone XML namespace parser return if given

I don't know why you call it "undefined" and it has nothing to do with
tightly controlled applications. Let's look at an example.

I am a single document parser which when parsing a document find three
relative links:

    "foo"
    "bar"
    "foo"

because I know that I am a single document parser, I know that within
the context of a single document, "foo" and "bar" can be used as unique
identifiers. I can therefore deduce that the first and third links are
identical. Coincidentally, existing tools that use literal
interpretation would have come to the same conclusion.

Now say that I start parsing multiple documents at the same time. In a
second document, I may also find a relative link "foo" but if the
context of this document and the first document I parsed is not the
same, then I can't deduce that "foo" in the second is really the same
identifier in document one and document 2.

The proposal states that it is the responsibility of the application to
know that it doesn't use relative URIs outside the context within which
they are defined. If you do that then you are already in trouble.

Henrik

Received on Friday, 9 June 2000 20:19:00 UTC