Re: Names, namespaces and languages

I don't disagree with the way you lay out the space, but I
do take issue with your concrete proposal, partly because
I find the complete disconnect with SCDs counter-productive,
and partly because I don't think it's cool to be imposing
requirements on the structures of the LHS URI. There is
also the whole vexed question of what to make of
vocabularies in no namespace at all, including some rather
important ones like DocBook.

I do think there are some middle ground to be found by
taking the _path_ syntax part of the SCD draft and using
it in a context with different rules for namespace bindings
that allows for a simpler fragment syntax for limited uses.

Schema component paths currently have the characteristic that
they may refer to more than one component. That is, the path
//element::xh:p refers to all the elements named p in the
namespace bound to xh. Namespace binding is outside of the path
itself, and the current draft licenses any kind of namespace
binding one wants, and leverages the xmlns XPointer scheme
when the paths are used in the xscd XPointer scheme. The
current draft is silent on whether //element::p can ever refer
to p in the default namespace, as opposed to p in the null
namespace, although we did recently decide to outlaw the
default namespace applying to paths.  While the paths may
refer to more than one component (or none), the semantics of
this path are defined in the context of a particular graph of
schema components.

One look at this set of facts is to see that the path semantics
are defined in terms of a particular set of components, and
conclude that they therefore have nothing to say about the more
abstract concept of "the XHTML p element". I believe this is
Henry's position, and I understand where its coming from.
I think there's another way to look at this, however. One way
to make sense of the abstract concept of the XHTML p element
is to regard it as the set of all possible specific XHTML p
element definitions.  A schema component path can be used to
find a particular component (or set of components) in the context
of a particular schema; but it can be used to identify any and all
such potential components out of the context of that particular
schema.  [This smacks of quantum mechanics, somehow: the
probabilities collapse when you actually go take the measurement.]
Yes, this is something of a pun and something of a bit of mess
ontologically; OTOH, I would argue it is the same messiness we have
whenever anyone dereferences an namespace URI and gets something
concrete back.

Concretely, if one uses the namespace name to provide namespace
binding to the default namespace on the LHS and a raw schema
component path on the RHS, one gets identifiers of the form

http://www.w3.org/2001/XMLSchema#/simpleType::dateTime

which is precisely one character longer than Henry's proposed

http://www.w3.org/2001/XMLSchema/simpleType/#dateTime

(This would, note, require a change to allow a binding of
the default namespace to apply over paths.)

This still leaves open the question of what to make of
non-namespaced vocabularies. I'm not sure there are any
pretty answers here.

There is something deeply unsettling about saying that
    #/element::caption
is a fine reference for the "non-namespaced caption element" on
the account that, well, the LHS must be empty because there is
no namespace URI. Maybe its DocBook, maybe its Joe-Bob's House
of Spam Vocabulary, who knows? But architecturally, using a
relative URI for a global reference is wrong, wrong, wrong.

I could also see getting around this through some hack of defining
the non-namespace namespace name, e.g. http://www.w3.org/2005/null
You still can't tell which non-namespaced vocabulary it is, but,
gosh, if you wanted to tell your vocabulary from everyone else's
you should have made a namespace for it!

On the other hand, one can very well refer to the caption element
in a particular schema, or to take this example:

http://www.w3.org/TR/2001/NOTE-daml+oil-walkthru-20011218#xscd(/simpleType::over12)

Yes, its more complex. But this is a more complex case. The lack
of a namespace makes it so: it means the LHS is something concrete,
an XML Schema in this case, with a MIME type that is XML and therefore
XPointer comes into play as the fragment syntax. There is some sense
that in putting what was put on the LHS, one cannot have any expectations
of generically referring to the "???mystery vocabulary?? type over12"
in the first place.  Further, the path itself looks the same, and I
consider this a very great plus; the same kind of plus that says that
there is some goodness in having namespace names look like regular
document URIs and frequently work like them as well.

//Mary

Received on Tuesday, 28 June 2005 17:00:30 UTC