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

Re: looking for packaging, not a schema

From: <keshlam@us.ibm.com>
Date: Thu, 18 May 2000 09:47:26 -0400
To: xml-uri@w3.org
Message-ID: <852568E3.004BC148.00@D51MTA03.pok.ibm.com>
>This is the crux.  The namespace URI will end up having lots of associated

Our first goal _must_ be to make Namespaces work. That's the question on
the table.

Nobody has yet proposed a way to reliably process an absolutized relative
name that will support the Namespace spec's primary goal: unambiguous
recognition of which elements and attributes belong to a particular

Binding to associated data is a fine thing, and I do expect evolution in
that direction. But I really don't see a need to force namespace _names_ to
serve this role. It can be achieved without the namespace name having to be
a URI at all, as my xmlns-binding: proposal showed.

In fact, the XML Schema Working Draft proposes a variety of binding
mechanisms, directly or through packaging, in which the namespace name is
only one of a set of possible hints about location... and which makes no
assertion that the namespace name is itself the URI (relative _or_
absolutized) of a Schema. See http://www.w3.org/TR/xmlschema-1/#schema-loc

It seems to me that, given this evidence that solutions exist, binding
isn't going to be a problem. So let's go back to focusing on what must be
done to make the namespace spec work. Please?

Admittedly, relative namespace names may be a borderline case. It is true
that if people never use relative URIRefs as their namespace names,
Absolutize causes no harm except to waste cycles. (Which may not matter on
a document-by-document basis, but may add up for heavily loaded servers.)
But after absolutizing, a relative name is no longer reliably recognizable
as a particular namespace... which means we're spending cycles in order to
_break_ the namespace spec along this border.

I'm very afraid that if we adopt this solution we will wind up with two
incompatable sets of documents -- those with absolute names which can use
namespaces as designed, and those with relative names which are using only
the namespace syntax (because that's all that will work) and reassigning
this syntax to other purposes. I submit that the latter is abuse of the
spec, and would not be compatable with the goal of consistant web
architecture; having something declared as a namespace which isn't a proper
namespace is at least as damaging as having something declared as a
string-in-URI-syntax which isn't automatically absolutized... and I would
argue more so.
Received on Thursday, 18 May 2000 09:48:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC