Re: Database example was: The Kesselman/Connoly proposal

>>Statement of bias: Personally, I don't expect to see such a semantic
before
>>the XML 3.0 timeframe.

>By semantic, I assume you mean what it means.  This is defined in the URI
>specification.

Mismatched antecedent. I wasn't talking about matching URIs (which I agree
is well-defined), but the higher-level semantics -- what concept someone
would have been trying to express that caused them to specify a relative
reference to a namespace.

We've agreed that we can give a context-dependent namespace declaration a
plausable interpretation at the mechanical level. What we haven't agreed
upon is whether that interpretation is actually useful given the roles
namespaces are design for and expected to play in the forseeable futures.

>... you  would expect that TWO MAJOR revisions of XML would have to happen
> before this mess is resolved propoerly

OK, a bit of hyperbole. I don't think two major revisions would be
required, but my perception was that it might take us that long to reach
consensus on what relative references to namespaces were actually useful
for, if anything. Note that this does _NOT_ imply a delay "before anyone
could build on top of XML
using the URIs of namespaces", only a delay before _relative_declarations_
of namespaces are well enough motivated to justify supporting them.

>The former - an architectural vision in which relative URIs are allowed -
>is simply the consistent invokation of the URI specification by the
>XML-Namespaces specification,

Maybe we're using terminology differently. I see that as a mechanic rather
than an architecture, and as such it's not good motivation. Your argument
seems to be "Namespaces declarations should be URI references because they
are references to the URI which is used as the namespace's identity" --
which is consistant as a flat assertion, but doesn't help us establish why
they should be considered references rather than assertions.


> every thing else in the web uses URI references

Nope. Element and attribute names aren't URI references. Most manefest
constants (eg enumerated attribute values) aren't.

And even if one accepts URI syntax, the existance of URI References should
not imply that it's impossible to talk about an explicit URI.

Namespace declarations, as far as the current architecture goes, are more
similar to this class of identifier than they are to those where URI
References are now being used. I'm still looking for a really convincing
motivation for moving them from the former group to the latter.


>"[Definition:] The attribute's value, a URI reference, denotes the URI
which
>is the namespace name identifying the namespace. "

That's the Absolutize proposal in a nutshell. We know it can be phrased
simply; that's true of almost every proposal we've considered. What we're
debating is which one yields useful behavior.

Consistancy is great. Applying it blindly isn't. Sometimes things _aren't_
sufficiently similar to be considered subclasses of the same base.

>Is it possible for you to find that it "isn't actually necessary" when
>someone else finds that it is is?

Of course. I was stating my own expectation of the long term result for the
community as a whole. I certainly could be wrong.

The question remains: Do we attempt to support relative syntax now despite
known costs, in case it does turn out to be needed... or do we reserve it
until we have a specific plan for how it will be used?

>Whose socks exactly, and what does it take to knock them off?

Speaking for my own: What it takes is a real architecture -- not just at
the micro  level of "here's how you evaluate a reference", but a clear
statement of what it means at a conceptual level for a document designer to
deliberately use elements and attributes whose identity changes each time
the document is relocated, and why this will further the goals of the Web
in general and XML in particular.

I've been convinced that having the names be URIs has significant value.
I'm still trying to convince myself that having namespace declarations
permit references to those names have similar value.


>I am still I think happy for relative URIs to be warned against
>as an emergency measure so we can make progress - but not if progress is
>then rolled back to some XML 3.0 date!

If we can find agreement quickly, great. Given the speed at which the
current debate is moving, and the trends (or lack thereof) that I've been
seeing, I fear that it may take quite a while longer than anyone would have
expected. That's all I intended to signify.




Reviewing your example: Maybe I'm misunderstanding it, but it doesn't
actually seem to address the key point under debate.


>It creates a namespace specifically for expressing data from that
database.

I'm having trouble wrapping my head around why it's doing so. You've been
telling us that a namespace is a language, or at least a vocabulary; your
use of the phrase "xml-schema namespace" later reinforces this.

"Data from that database" doesn't fit neatly into that model. It states
where the information is hosted, not what language it's expressed in. There
is some indirect contextual meaning implied by the fact that you retrieved
it from this database rather than another... but it doesn't seem to me that
a namespace name is the right way to express that.

Maybe I need a more concrete example in order to understand your intent.

>the namespace for encoding data from the database is (relative to the
>above) foo/ns.

Nitpick:  that's the namespace _declaration_. The intended namespace
identity "is" URI http://internal.example.com/2000/05/foo/ns

(Sorry to quibble, but this distinction has been a major source of
confusion in this debate.)


>When asked to render this by a client understanding XML, a
>document is returned written in the xml-schema namespace

That's one particular use of the namespace name, and not one either
endorsed or forbidden by the Namespace spec.

It could as easily return a document written in any other
namespace/DTD/schema. Or a non-XML representation of the resource. Or some
form of index to the metadata for this namespace. Or referencing this URI
may cause certain persistant side effects. Or the reference attempt may
fail outright.

Note that even if we accept the desirability of retrieving data associated
with a namespace, it's been demonstrated that there are many mechanisms for
doing so that do not require that the namespace name as declared be a
direct URI Reference. Bindings to URI References can be asserted within the
document, or the name can be used as a key into a catalog, or...


This seems to motivate relative pointers to metadata assocated with a
namespace -- which makes sense; interpreting a statement in a given
language may indeed require understanding the context in which it was
uttered.

It really doesn't seem to motivate a relative pointer to the namespace
identity. The basic definition of the language itself does _NOT_ change
because the discussion is hosted in a new location. If it does, then I
submit it is no longer the same language, and should be given a new name.







You're presu






______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 30 June 2000 13:29:10 UTC