xml-dev - Treaty of Wulai (was Re: simple question on namespaces.)

[Rick Jelliffe <ricko@allette.com.au>]

 From: Uche Ogbuji <uche.ogbuji@fourthought.com>

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

The long-recognized problem, that some people insist that the URI must
reference a schema (e.g. SOAP), is now joined by another problem, where some
other people now think it must not reference anything.  Without an internal
convention for representing versions, namespace URIs are not powerful enough
to support generic processing with an evolving schema, so the first view
(however attractively simple) does not seem workable. But all that the
second view denies is that, given that a schema can be decorated with a lot
of <appbells> and <appwhistles> which will allow more sophisticated generic
processing by schema-aware systems, there are some instances which all
processing can be tied to the schema version which is 1:1 with the namespace
URI (not needing another resolution step or mechanism, and being upgraded
with each version).

I think lurking under all this is the deficiency of the "data" versus
"document" distinction. What we really have, I think, is more a distinction
between
  1) generically processable using only information retrieved from the
particular schema;
  2) not processable without non-schema-representable information;
  3) (for orthogonality) processable just as generic XML.
I think a lot of the namespace=schema people have documents which fit into
the first class. I suspect some of the people for whom !(namespace=schema)
is true have documents which fit into the the latter two classes.

The reason I bring up data-versus-documents is this: proponents of
namespace=schema bring up data-versus-documents where they really seem to
mean generically-schema-processable...import of data between databases for
example. However, documents that are somehow executable (e.g. SVG, XSL,
Gavin Nicol's XEPR, SOAP headers) are not "data" in the sense that generic
processing of them according to the information added by a schema will give
us much of the value; but they are not "documents".

I think that, in the absense of any other considerations, data in class 1)
above is best handled by having a schema directly retrievable from the
namespace URI. I think for documents in class 2) above, having a schema
directly retrievable is a mistake for maintenance reasons at least.

I should point out that, in these cases, it is not really the data that
belongs to the classes, but the kinds of applications that use the data.
That being the case, the question comes down to whether the person creating
the data has control of the applications using it: if they have, then they
can use namespace URI=schema URI, if not (for reasons of deployment of
applications, time and maintenance, public  publication, etc.)

 > However, now we have XSchemas, and there is a sizable body of
conventional
> wisdom that suggests having an XSD at the business end of a namespace URI.
> I'm not sure where this CW comes from, but I have heard and read it often.

An interesting rub is how the Schema WG has treated the schema frament for
XML namespaces, given that there are different schemas for different
versions.  Each version has a unique URI, but there is another URI which
locates the most recent version. While eventually one hopes XML Schema's
syntax will be fixed, nevertheless people may still want to make different
versions of the same schema (e.g., to add <appinfo> for specific purposes.)
So when talking about whether a schema should be retrievable from a
namespace URL, we also have to consider (for maintained schemas) which
schema it should be.

This certainly leads to the expectation that there will be many uses of
namespaces where the namespace URI represents a fairly generic naming
mechanism, which does require other mechanisms for finding specific
information for optimal processing. The schemaLocation  attribute does this:
it is called a "hint", but I suspect that any system where the data is not
class 1) above (generically schema processable) should use the hint in
preference to the namespace URL when attempting to retrieve a schema.

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

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.

Having said all that, I certainly agree that more is needed; I don't know
that this needs to be an expanded form of the namespaces spec (which perhaps
needs an update anyway, now that XML Schemas has gone for 3-part "symbol
spaces" rather than two-part Qnames.)

> All sides certainly have enough ammo to bring to a War over Namespace
> Semantics.  Why should we not engage?

Because no-one will win. The issues IMHO may ultimately come down to
questions of application controllability and not technical issues.  So it
will divert people from actually putting out interesting and useful tools.
Are our lives so long?  If they are, could we have it on another list,
perhaps namespace-bores@egroups.com ?

I propose instead we have a Millennial Namespaces Treaty of Wulai (named
after the hot springs where I have been soaking today, looking out at a
waterfall on the pretty green opposing valley, feeling like a boiling egg
with no timer), where we all agree that in some limited but important
circumstances (namespace URI=schema URI) makes sense, and should be allowed,
even though the general case should not support (namespace URI=schema URI),
though in no case does (namespace=schema).  Then the discussion would be on
how to cope with this diversity both hygenically and respectfully.  In
particular, what should UDDI's role be in all this?

Cheers
"Three Minute" Rick Jelliffe