xml-dev - Re: Treaty of Wulai

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

As usual, Rick, you expose places where I was unclear.  Thanks.

> > Paul is not the first to point out the essential contradiction of the
> > Namespace WG in saying that namespaces are opaque, meaningless strings in
> > one breath and then saying that they are URIs in the next.
>
> I don't think there is a contradiction. A name can be used for multiple
> purposes.
> The URI is *used* as a namespace name. And it can be *used* to locate some
> retrievable
> information. And that information could be a schema. Or, if http: is used,
> we expect it
> to retrieve something about the namespace.

No doubt a name can be used for multiple purposes.  That wouldn't be the
contradiction.

Back to the spec

"An XML namespace is a collection of names, identified by a URI
reference..."

"URI references which identify namespaces are considered identical when
they are exactly the same character-for-character.
Note that URI references which are not identical in this sense may in fact
be functionally equivalent. Examples include URI references which
differ only in case, or which are in external entities which have
different effective base URIs."

And that's all I see there.  Am I missing something?  I don't see the
rider WRT relative URIs.  I don't even see that the latter quoted
sentence has been modified to reflect this prohibition.

But anyway, this shows that there is no contradiction in the spec itself.
The contradiction seems to be in the interpretations of the spec given by
its editor and other very respectable parties in discussions by the spec.

Again Tim Bray:

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

*There's* the contradiction.  The spec doesn't prohibit meaning of
namespace identifiers and so RDF, SOAP and the CW of namespace=schema
have nothing officially in their way.

But based on your comments, I think it might just be the usual quiddity
over the meaning of "meaning", so I'll move on.

> > In the spirit of "worse is better", I think we need to begin this
> > conversation *now*.
>
> Yes, but not to go over endlessly the debates of the past, which was Tim's
> point.  The 1700 emails on the public mail-list about relative URLs followed
> hundreds of emails on private W3C lists and ended up at exactly the same
> point as the private lists ended (deprecation).

Again I was unclear, and contradicted myself in the wording (see, pretty
easy to do).

I did intend to disavow the war over what namespaces must mean.  You are
right that this would go ten times the famous 1700-message flame-war without
satisfactory resolution.  It so happens that on this point I am in the
minority, including Tim, which thinks that namespaces should have no
additional meaning.  Given that they are already URIs, I think that
applications should not try to resolve namespace URIs for any purpose in
the normal course of XML processing (whatever that is).

Of course, this is an impractical view given that people expect to be able
to retrieve something at least from URLs.  I accept this, and it's after
this acceptance that comes the war I had in mind.

What I would like to be hashed out is a structure for defining the semantics
one attaches to namespaces.

At its most basic, this could just be a distinction similar to that of
well-formed/valid in XML 1.0.  Processors could be placed at two
distinct layers: one that only treats namespaces as syntax and one that
allows using the information represented by the URI itself for processing.

Within the latter layer, hopefully there would be some mechanism (even if
just prose guidelines) for clearly expressing what semantics are intended
by the XML application itself (I mean "application" in the strict sense,
what is often called "vocabulary").  This way one processor could operate
on both RDF and SOAP and be able to handle the very distinct ways in
which they apply semantics to namespaces.

> So I am trying to suggest is that we do not have a problem with namespaces
> or URIs here. Rather, it is the age-old problem of generosity: allowing the
> namespaces spec to be big enough to cope with both class 1) and class 2)
> applications above, and defending it against attempts to force it one way or
> another.

You are right that theoretically there is no problem.  The problem comes
only in practice, when there is enough pressure applied by the common
behavior of XML applications and processors to indeed force it one way or
another.  Is it not better to put up a flexible framework such that no
forcing is necessary?

> Having said all that, I certainly agree that more is needed

This is the core of what I was getting at.  The problem I was was that
people are using the sound *theory* of XML NS 1.0 to wave off challengers
such as Paul (and Simon St. Laurent before him, and others before Simon)
who bring practical concerns.  I do think that more specification needs to
be made of these matters, especially given the many "facts on the ground"
that have accumulated since January 1999.

I think that what we have here is the classic database problem of IDs with
"business" meaning.  It's well known among database designers (whether
relational, object or other) that it is a bad idea for IDs of database
entities to have any meaning within the application.  The
obvious example is that you don't use first initial plus last name as the
key field in a relational table.  The strong form of this principle,
however, says that even if you use sequences or random numbes, that you
shouldn't use this field for any application-level processing.  If you do,
even though it originally had no meaning, it will acquire meaning through
the behavior of applications and end-users.  This meaning will interfere
with extensibility and consistency between apps.

The ODBMS folks go to great pains to hide object IDs for this reason.
Another technology, COM, that came a cross a similar problem as XML 1.0,
invented GUIDs as a near fool-proof means of avoiding any application of
meaning to digambiguating identifiers.  The very ugliness of GUIDs ensures
that they won't be exposed except at the low-level COM layer of the
application, as intended.

I understand that because of the nature of XML, the WG couldn't easily use
any of these tricks to avoid the semantic trap.  Given that XML namespaces
inevitably have meaning, I think there needs to be some effort to ensure
extensibility and consistency of XML applications and processors.

'Twould be nice if we could all soak in the waters of Wulai (or y'all
could join me in Steamboat Springs) and delicately craft such a framework.
Something tells me this is unlikely.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python