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

Re: Moratorium proposal

From: <keshlam@us.ibm.com>
Date: Wed, 12 Jul 2000 09:46:34 -0400
To: xml-uri@w3.org
Message-ID: <8525691A.004BA885.00@D51MTA03.pok.ibm.com>
>>If it returns different results each time, or different
>>data for each user, or keeps an access count or other side-effect data,
>>that's up to it and is out of the scope of the URIs and schemes.

>So whose scope is it?

It's the scope of whoever defines the schemes and/or the services that
respond to those schemes. URIs only define an address space. The objects
that occupy that address space have their own specifications.

> Does this imply that Namespaces in XML was reckless
>for failing to specify further expectations?

No. It reflects the fact that Namespaces chose a specific problem to
address -- that of providing a naming convention which will work across
document types (including non-validated documents) -- and left the field
completely open for other folks to build on that base.

Namespaces are a syntax enhancement. That's all they are. It may or may not
be desirable to associate additional information with them, but the
namespace spec itself says nothing about what information may be associated
or how that association is asserted and processed; at most, it provides a
hook upon which further specs may be built.

We may adopt a standard for how to bind namespaces to metadata, and what
kinds of metadata can be bound to. Or we may adopt several, to suit
different needs (just as no one XML language fits all tasks). Or we may
continue to see experimentation with custom solutions. The Namespace spec
has no opinion on that, any more than the XML 1.0 spec does.

>  Or that we should take
>literal comparison at face value and assume that literals are all the
>expectations we should have?

That's largely independent of the question of meaning... unless we reach
agreement that one of the meanings that the W3C wants to actively support
actually requires relative syntax in namespace declarations. At that time,
we will have to decide how those values are to be stored, presented, and

I think it's clear that we need a clearer consensus on an architectural
vision before  attempting to nail down the behavior of specific syntax.
It's probably worth continuing to explore that issue. In the meantime,  the
Deprecate/Undefined proposal seems to be the only stopgap we're likely to
agree upon -- it explicitly admits that more work is needed in this area
before any definitive statements can be made, tells folks who require
portability what values to avoid until this is resolved, and leaves room
for experimentation.

It also leaves room for divergence. But I think our problem is that there's
already a divergence of expected applications. Some group needs to sit down
with these, work through them, determine what their real requirements are
(independent of the syntax in which those requirements are addressed), and
then decide how the behaviors which address those requirements are to be
expressed in XML.

Personally, I suspect that a serious attempt to go back to first principles
and basic requirements will discover that relative syntax in namespace
declarations is, in fact, not necessary and causes more trouble than it
solves. But we won't know until we have a real design in progress. Until
then, we're just waving our hands -- which is a bad way to try to fly.
Received on Wednesday, 12 July 2000 09:47:30 UTC

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