W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: A little courtesy, please (resource questions)

From: Dan Connolly <connolly@w3.org>
Date: Tue, 23 May 2000 09:29:25 -0500
Message-ID: <392A95C5.B87E90D@w3.org>
To: David Carlisle <davidc@nag.co.uk>
CC: xml-uri@w3.org
David Carlisle wrote:
> 
> > Either namespaces are web resources in every sense of the word,
> > and hence any sort of URI reference the author chooses
> > may be used to point to them, or not.
> 
> Is a URI reference a web resource (the URI refererence itself, not the
> resource it points at) ?

It's not a straightfoward/traditional usage, but yes,
a URI reference "./foo" is a resource that can be
referred to using the URI

	data:,.%2Ffoo

> Can you give "any sort of URI reference" to a URI
> reference?

Looking at a URI reference as a resource, which is not something
one does very often, but ... yes, given a base URI B,
any URI reference R for which
	urlparse.urljoin(B, R) == "data:,.%2Ffoo"
is a fine way to refer to "./foo" as a resource.

(c.f. urlparse.urljoin in the python library
http://www.python.org/doc/current/lib/module-urlparse.html
or any other implementation of
the algorithm in section 5.2. of
http://www.ietf.org/rfc/rfc2396.txt )

> Namespace names are by definition URI references.

Well, yes, that is the definition
written in http://www.w3.org/TR/1999/REC-xml-names-19990114/ .

But I don't think it's a good or even reasonable definition,
and it's not the definition that several folks has in mind
at the time:

"To me it was obvious
that what you would compare character-for-character would be the URIs
after absolutization, and I had thought that it was possible to
interpret the XML Namespaces Rec consistently with that."
	-- Fri, 19 May 2000 11:38:43 +0700
	http://lists.w3.org/Archives/Public/xml-uri/2000May/0218.html

As has been said many times, most recently/clearly in Joe K's
summary, one of the proposals on the table is to change
the definition of 'namespace name' to say that rather than
being the literal value of the xmlns attribute, is the
absolute form of the xmlns attribute value after expansion
w.r.t. the base URI.

cf OPTION 2: ABSOLUTIZE RELATIVE REFERENCES.
in mid:852568E7.0071E352.00@D51MTA03.pok.ibm.com , i.e.
Joe's message of Mon, 22 May 2000 16:43:56 -0400
available at
http://lists.w3.org/Archives/Public/xml-uri/2000May/0381.html


> > and if not, the design
> > of XML namespaces doesn't agree with web architecture, which
> > is that important things should be treated as web resources
> > with all the rights and obligations thereof.
> 
> I can't construe any meaning to this statement, it's clearer
> when you stick to:
> 
> > I prefer to discuss these issues in black and white terms
> 
> > using test cases ala the two bats,
> 
> Which case admirably shows why the namespace names should be taken as
> (as specified) the URI reference rather than the absolute URI. With your
> proposed change to the namespace rec your document becomes some sort of
> unstable underspecified non-document that can not in general be queried
> or styled as the element names are underspecified.

Please elaborate in detail about what is underspecified about the
documents in my message
http://lists.w3.org/Archives/Public/xml-uri/2000May/0137.html
under "OPTION 2: ABSOLUTIZE RELATIVE REFERENCES."

Given a base URI, say http://example.org/xyz/,
the absolute URI+ designated by the URI reference in
	xmlns="../2000/vocab#"
is exactly as well-specified as the absolute URI+ designated by
the URI reference in
	href="../2000/vocab#"
in any HTML document. That is:
	http://example.org/2000/vocab#

> > I largely agree with this, but I cannot agree that treating relative
> > URI references as namespace names without absolutizing them is in
> > the spirit of RDF.
> 
> what about other suggestions raised such as using uuid or mid URI
> schemes, what happens to the validity of a mid: URI if you stick an
> element name on the end a la RDF?

Umm.. nothing but the obvious.
The RDF "concatenate the localname with the namespace name"
is something that I'm still not sure I'm happy with, but
the specs are clear enough; e.g. take
	mid:852568E7.0071E352.00@D51MTA03.pok.ibm.com
and append
	Creator
and you get
	mid:852568E7.0071E352.00@D51MTA03.pok.ibm.comCreator
which is still a perfectly good mid: URI.

By "validity" of a mid: URI, I assume you mean that it meets the
constraints of the mid: spec
	http://www.ietf.org/rfc/rfc2111.txt

There are some snarly interactions between RFC822 message-id
syntax and non-ASCII characters in URIs in XML (section 4.2.2
External Entities of XML 1.0
http://www.w3.org/TR/1998/REC-xml-19980210#sec-external-ent). For
example, the document:

	<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
		xmlns:myNS="mid:852568E7.0071E352.00@D51MTA03.pok.ibm.com">
	  <myNS:sousPropriétéDe/>
	</rdf:RDF>

then the class name used in the child name is

	mid:852568E7.0071E352.00@D51MTA03.pok.ibm.comousPropri%X1%X2t%X1%X2De

(for %X1%X2 please read the utf-8 encoding of é.)

This meets the constraints of general URI syntax, but it's
not a valid mid: URI, because when you URI-decode the stuff
after mid: , the result doesn't parse as an RFC 822 addr-spec
as required by RFC2111.

So don't do that; i.e. don't use names containing non-ascii characters
combined with mid: namespace names that don't end in / or #
as RDF property names

I'm still not sure why you asked those particular questions, but
I hope I've made clear that the answers to them are simple
matters of fact to be found in the relevant specs.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 23 May 2000 10:30:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC