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

At 01:27 AM 2000-06-02 +0100, David Carlisle wrote:
>
>Tim Berners-Lee> I don't think this is a time for compromise.
>Tim Berners-Lee> Yes, it is a compromise.
>
>Hmmm.
>

So much for The Director being a Eastern potentate who never listens.

You failed to mark the fact that these quotes are from different messages
at different times, no?

>> * 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.

What transaction requires that there be a name?

I thought that we had established that there is no need to refer to the
namespace.

>It can't forbid them without orphaning a lot of existing documents.
>
>> 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.

What depends on the definition?  Actual operations, value added?

Processors of a particular namespace can always recognize their proper
instances to process by the matching method provided in the existing
Recommendation.  That is a supported operation.
Why can't RDF follow suit?  Why does it think it has to have a name?
That's a capability-gutting restriction.

What we need in our language-building toolkit is rule language.  This is
based on the capability to make assertions about instances of
as-yet-unknown identity that match a stated acceptor pattern.  Named things
are a special case, not the general capability.  The Namespaces WG has done
us a backhanded favor by giving us this existence proof of a class
(document instances sharing a common namespace) which has no name but a
well-defined match pattern.  

>
>
>> 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
>
>`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.
>
>> 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)
>
>> - 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.

Simon is right that the devil is in the details.  

But by Tim saying that the cited document could contain xml-schema does not
mean that thereby the other information will be relegated to a lower class
or will be unrecognizable or unusable.  The cited resource could include
format-sensitive information like a DTD by reference, so that the tool
machine-applying the DTD wouldn't have to sift through a flabby document to
find the material germane to it.  Or it could be a "literate programming"
doucument where the extraction to the/each machinable subset is well
defined and easily done.

Al


>
>David
>

Received on Friday, 2 June 2000 10:00:18 UTC