OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: simple question on namespaces.

[ Lists Home | Date Index | Thread Index ]
  • From: Jonathan Borden <jborden@mediaone.net>
  • To: Paul Tchistopolskii <paul@qub.com>, xml-dev@lists.xml.org
  • Date: Thu, 28 Dec 2000 02:42:17 -0500

To prevent unsuspecting individuals from getting confused, I would like to
state several facts:

1) all namespace names must be URI references by definition
2) all URLs are URIs by definition
3) all URIs are URI references by definition
3) a string of the form "http://foo.org" is both a URL and a URI
4) a string of the form "http://foo.org/bar.txt#baz" is a URI reference
5) a string of the form "www.whatever.com/foo.bar" is NOT a URI reference
and hence may not be a namespace name
6) The namespace recommendation attaches no specific meaning to the URI
reference which serves as a namespace name.

read http://www.w3.org/TR/REC-xml-names/#dt-NSDecl (Jan 14, 1999)
read http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt (August 1998)

I'm sure there were many lively debates regarding the syntax of the unique
string which forms a namespace name as the rec was being developed as there
have been afterwords but the argument is moot. The only interesting issue
which has arisen is due to the EBNF definition of a URI reference:

	URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

which allows usage of a relativeURI in a namespace name. After much
discussion, and now reflected in the most recent WD Infoset, relativeURIs in
namespace names are deprecated. Usage of relativeURIs as namespace names
while conformant to the namespace rec, results in such document having no
defined Infoset (i.e. it is not Infoset conformant). This leads to the
following strong recommendation:

7) Don't use relative URIs in namespace names.

Jonathan Borden
The Open Healthcare Group

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@qub.com]
> Sent: Thursday, December 28, 2000 1:31 AM
> To: Tim Bray; xml-dev@lists.xml.org
> Subject: Re: simple question on namespaces.
> ----- Original Message -----
> From: Tim Bray <tbray@textuality.com>
> > <rant subject="namespace kvetching" frequency="every 6 months or so">
> > All attempts to assign meaning to namespace names (which are URI
> > references) are ex post facto and irrelevant to the aims of the
> > namespace recommendation, which is to make names unique for
> > practical purposes in the Internet context.  This is a useful
> > thing to do, and the namespace recommendation does it.
> That's exactly why I'm saying that http: should be removed.
> Too bad W3C namespaces such as :
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> are confusing people, *assigning* some meaning to
> the namespace names.
> xmlns:xsl="www.w3.org/1999/XSL/Transform"
> if better, because it better reflects what *you* are saying.
> Who is assigning meaning to namespace names? I think it is W3C.
> Not me for sure. I'm suggesting to *remove* the meaning.
> If W3C will use
> xmlns:xsl="www.w3.org/1999/XSL/Transform"
> it will be clear that namespaces really have no meaning yet.
> I think it was even better to use www.w3.org.1999.XSL.Transform
> Why it is :
> <rant subject="namespace kvetching" frequency="every 6 months or so">
> Because W3C is using URLs for namespaces, but *not*
> 'some unique strings with no semantics attached'.
> URL is *not* some unique string with no semantics attached.
> What was the rationale of W3C for doing that ? No answer yet.
> If "it should be just a unique string" why it does not *look* like
> just unique string, but every W3C namespace looks like a *URL* ?
> Why not remove http: - that will make in not a URL, but will have
> all the current  benefits of uniqueness ?
> Rgds.Paul.
> PS. I have a strange feeling that I'm repeating myself. I apologize
> and will not participate in this thread any longer.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS