Re: Base-less fears (was Moving On...)

Jonathan,

At risk of a little repetition I will go though the specific messages you
mention.
I am sorry  if I have omitted to respond to some messages - sometimes I had
felt that others on the list had responded adequately.

-----Original Message-----
From: Jonathan Marsh <jmarsh@microsoft.com>
To: 'Tim Berners-Lee' <timbl@w3.org>
Cc: xml-uri@w3.org <xml-uri@w3.org>
Date: Thursday, June 01, 2000 7:46 PM
Subject: Base-less fears (was Moving On...)


>> -----Original Message-----
>> From: Tim Berners-Lee [mailto:timbl@w3.org]
>
>> Re-issue namespace spec saying:-
>>
>> * Confirm that the namespace attribute is a URI-reference
>> * Point out that that this implies that litteral comparison and URI
>> comparison are
>>   equivalent so long a  relative URIs are not used;
>> * using relative URI references is  a bad idea, because
>> existing software
>>    does different things with them.
>
>I would be very pleased if you could explain how this could be made to work
>in light of the objections I raised in
>http://lists.w3.org/Archives/Public/xml-uri/2000May/0511.html and


__________________________________________________________________


-Message-ID:
<116DFD732FA92E4D9B647C8EEF6DAF1015E1FD@red-pt--02.redmond.corp.microsoft.co
m>
From: Jonathan Marsh <jmarsh@microsoft.com>
-> From: Tim Berners-Lee [mailto:timbl@w3.org]

-> The namespace spec, we now realize, breaks relative URIs as
-> defined in an IETF specification of long standing and great
-> use.
-
-Accepting that as true for the moment, what do you propose to do about it?
-
-To bring Namespaces into line with the expected handling of relative URIs
-means that each document must have a base URI at all times, which is
-currently not the case.

This is nonsense. Only documents which use relative URI-references need to
have base URIs, and then only those for which there will be comparisons
made against other URIs.

The situation here is the same as for images on web pages, which lots
of people deal with quite successfully all the time.  The author of a
document
*may* use a relative URI reference in cases when he or she will ensure that
the bits will not be resued inappropraietly - ie as a representation of a
resource which has a different base URI and such that the resulting absolute
URI for the namespace would cause an error.  That author will also have to
be aware that different software may treat the realtive URIs differently
because
of the ambiguity in the namespace spec.

I gave, in
http://lists.w3.org/Archives/Public/xml-uri/2000May/0281.html
, a specific example of a virtual namespace in a situation very similar to
that introdcued by Michael Rys.

-Otherwise, a case of "disappearing names" results.
-Is making something as fundamental as element names context-sensitive a
good
-design?  I don't see how it could be, and David Carlisle has done a good
job
-of providing examples and scenarios of the dangers involved.

I think the community has, I hope, a good understanding of what happens when
you misuse a relative URI.   This is well known.
I would not expect them to be used for a namespace except in the case of
a virtual namesapce (or a mutually self-referential schemata).

My proposal includes a warning about the dangers of relative URIs.
So I am not sure why you meantion this message as a counter example
to that proposal.

-So if we absolutize for the sake of URI consistency, we also have to forbid
-relative URIs so that names are indepedent to changes of document location.
-Of course, if we forbid, we no longer have to absolutize.  Absolutization
-and forbidding amount to essentially the same thing.

You rule out the use of namespace in the example I quote above.
This may not be the way *you* want to write your documents, but
I do not feel it is approipriate for you to forbid others to, or to write
software
which is capable of understanding them if they want to.

-While I was initially fairly open about whether absolutization or literal
-string comparisons is the right way to go, forbidding clearly is impossible
-without either breaking trust in the W3C or versioning Namespaces, as
-forbidding is incompatible with existing docments in both theory and in
-practice.

Larry Masinter has pointed out that it is no crime to make documents
non-conformant by a more recent version of a specification in the name
of progress. What matters is when systems break. I have given many examples

-If we do version Namespaces, what compelling benefit is there to adopt it?
-Nothing concrete that I can sell to customers except a promise of the
hassle
-of changing all their document version numbers, and so a new version is
-susceptible to becoming an intellectual excerise and not solving real
-interoperability problems.  If you recognize that and want to go ahead with
-it anyway, fine - but don't complain if adoption flops.


The fact is that existing documents and systems rpobably won't break,
because the
difefernce in processing only shows its head when more than one base URI
is involved.  Most systems at the moment deal with only one document.
The DOM deals with only one document. We don't have XInclude yet.
The system as it is wll break as XML systems becaome more complex.
We can however fix it now with relatively little damege.

-In order to elicit more response from you about this problem, I'll
-re-propose a hack that attempts to address the competing demands of URI
-conformance and name stability.  Note that I'm not _advocating_ these
-positions.

If you are not advocatingthe position then I don't see a need to respond to
it
really.

-1) Define somewhere (XML Base?) that all XML documents in which the base
-cannot be determined default to a constant value for their base URI.  Thus,
-documents can never be in an environment where base URIs don't exist, and
-names can always be determined.  Then choose that either ...

You can't do this.  The URI specification defines the base address. This has
been pointed out
on the list.

[...rest of your point 1... ]

-If you have any better ideas on how to reconcile URI conformance and name
-stability, I'd love to hear them.  If they aren't reconcilable, it comes
-down to a judgement call (which appears to be the current state of
-discussion) and I'd be interested to hear your view on why name stability
-should lose out.

Your comment would make sense to me if relative URI references were being
made mandatory. They are only being made legal (and warned against).

- So far you've done a good job I think explaining why URI
-conformance is a good thing,

Thank you

- but not why name stability is not also a good
-thing, or why URI conformance is more important than name stability.

I hope that the later discussions ofdiiferent very stable types of URI
will have convinced you of the significant power you have to make a
very stable reference with a URI, such as an mid: or a uuid: if
an http: reference worries you.

-- Jonathan Marsh
-  Microsoft
_______________________________________________________________





>http://lists.w3.org/Archives/Public/xml-uri/2000May/0577.html, and to which
>John Cowen responded with what I believe is the highest praise: "This is
>IMHO a *very* strong argument." in
>http://lists.w3.org/Archives/Public/xml-uri/2000May/0578.html (hopefully
>that will pique enough interest to follow the links :-).


To save readers the bother, here is I think the relevant excerpt:

<snip>

Marsh:
-> If names are absolutized, during the time the document is in the pipe, it
is
-> simply not a legal document according to the namespace spec.  Accounting
for
-> this enforces substantial limitations on the useage of XML not well
-> justified by current practice, and requires a redesign of many (all?)
-> namespace-aware interfaces (standard or otherwise) to XML documents.

Cowan:
-Yes, indeed.  This is IMHO a *very* strong argument.

Although the URI spec urges an implmentation to provide
a base URI in all context someohow, and although I think that for a unix
pipe the file://$host/$pwd/  defualt is appropriate,
and although in test cses of people playing with unix scripts that might be
what
was intended,
and although the C preprocessor uses relative URis for example for its
#include "foo.h"
function,
I would absolutley agree
that if something it to be piped into a program which can take no parameters
to give it a base URI of the stdin stream, that using relative URIs for
a document to be used in such a context would be most unwise.

Given that I just can't see anyone who knows what a relative URI-reference
is using
one for a namespace anyway,  I don't see that this need be a big problem.
The spec will have a warning on it.  The only problem seems to be folks
who use "foo"as it is and expect it to match against "foo" elsewhere - in
other
words do not use their knowledge of relative URIs.
But  no one has put forward a real application where absolutization would
cause a malfunction of the system.


-> Granted.  But you seem to concur with my basic assertion, that the end
-> result for the average user is the same - "don't use them".

-Yes.

I think we all agree here.
</snip>

back to your top level message.

>In that posting I argue that your statement "using relative URI references
>is a bad idea, because existing software does different things with them"
in
>practice is equivalent to "using relative URI references may cause your
>document to cease to be namespace-legal XML in certain contexts."
>
>This quacks like "forbid" in that it breaks existing documents.


Apart from the fact that no one has found an existing document which it
breaks
without making one up.

But for all this arguing,  you see I *have* come around to the conclusion
that as a compromise we should recommend against relative URI-references for
namesapces
so I think we maybe agree.

>I'd appreciate a response from you on this, it probably missed your notice
>in the flood.  Perhaps a new thread name will help :-).


You have your response. I hope it meets your expectations.  :-)

Tim

>- Jonathan Marsh
>  Microsoft
>

Received on Friday, 2 June 2000 20:11:08 UTC