Re: Moving on (was Re: URIs quack like a duck)

-----Original Message-----
From: David Carlisle <david@dcarlisle.demon.co.uk>
To: timbl@w3.org <timbl@w3.org>
Cc: xml-uri@w3.org <xml-uri@w3.org>
Date: Friday, June 02, 2000 3:32 AM
Subject: Re: Moving on (was Re: URIs quack like a duck)


>
>Tim Berners-Lee> I don't think this is a time for compromise.
>Tim Berners-Lee> Yes, it is a compromise.


I would raelly like not to compromise.  There has been a lot of resistance
to
a solution which is clean for the future, based on hoards of existing
documents.
</Sigh>

>Hmmm.


Hmmm..

>> * using relative URI references is  a bad idea, because existing software
>>    does different things with them.
>
>If it just does this, and doesn't actually forbid them then it has to
>answer the question `what is the namespace name of the element marked
>up as <x xmlns="x"/>' otherwise this whole discussion has failed.

Strictly, if it forbids them then it doesn't not have to say what that
means.

The namespace name in your example is of course only defined wherethe
document
has a well-defined base URI.  In fact, software could pass it though in
relative
form until a comparison is needed, and then thwo an error.


>It can't forbid them without orphaning a lot of existing documents.


Orphaning?  Making them non-conformant with the new version.

>> Software which absolutizes the URI-reference
>> and uses the URI will be legal. So will software which compares as
>> strings.
>
>That is already the case now. Obviously any software that is going to
>retrieve any resource based on the namespace name is going to make an
>absolute uri first. But still the namespace spec has to say what the
>namespace name is for all conforming documents (even documents that
>use features that are listed as unwise). Leaving this undefined
>would be just a failure of the entire process of this list.


Yes. I obviously prefer and would propose that the name be the absolutized
URI.

The C preprocessos has got by with allowing   #include "foo.h" for many many
years
and the whole C world has not falledn into a pit.

>> XPath does not need to be re-issued as it will interwork, as relative
>> URIs are excluded.
>
>They are not excluded unless they are forbidden. While it is true that
>applications layered over namespaces may retrieve resources using the
>namespace name (and thus of necessity form an absolute URI first)
>the DOM and xpath are software specifications that provide the
>interface to ask the question asked above



Ah, above? Above which sentence?"
What is the text of the
"the question asked above?

;-)   We can survive this change and it will be for the better.

>`what is the namespace name of the element marked up as <x xmlns="x"/>'



>So the dom, xpath, and the namespace spec all need to give the same
>answer, even if the entire construct is deprecated.
>I believe that the statement should be that the namespace name is as
>defined in the current namespace spec, the literal interpretation
>but that a warning should be made explicit that a) relative uri aren't
>globally unique names, and b) some software will use the namespace
>name as is and some will use the absolute uri obtained by combining
>the namespace name with the document base uri, and thus surprising
>results may trap the unwary.


So long as itis oK to build software which absolutizes all URI-references
when it instantiates the object refered to, then I suppose I could live with
this
in theory. But it would be so misleading as a direction for the future.


>> That would be a note.  I think that it might be a good idea to point out
>> for example that
>> - such a document is not mandatory
>> - the document may include xml-schema
>
>agreed. The fact that tying schema in particular to namespaces is a
>bad idea is a separate issue unrelated to this namespace uri issue,
>and in theory it might be the case that some namespace has (and only
>ever will have) one schema, in which case it might make sense to put
>the schema at the namespace uri. (I don't know of any namespaces for
>which this is true, but that doesn't mean that none exist)


The scema for schemas is one.
That is a separate battle, I agree, and I can see that you wish to be able
to define languages where there is no definition of document validity and
hence no schema, but that can wait for another day.


>> - a document can contain xml-schema and also other information
>
>That's not really the point, the other information is ignored by
>the schema validator so the document works as a schema, but will
>it work as an xsl stylesheet, or a dtd or a XDR schema or anything
>else that you want to associate with the namespace? The answer is no
>if the `other information' is second class compared to the schema
>information and has to be in a format dictated by the schema spec.


Why should the answer  be no?

Why can one not just mix the languages at the top level - or very close?

(There is a bug in the XML design that the concatenation of to XML documents
can never be an XML document but we can leave that for another day too :-)

In fact, because the document-level elemnt does have to be from a particular
langauge, it is true as you say that oethr information seem secondary. RDF
was designed assuming it mightbe embedded in other documents. So anything
you can express in RDF will be able to go in.  The rat of mixed language
design is in the early stages...


>David
>

Received on Friday, 2 June 2000 23:44:53 UTC