Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 16, 2005, at 16:23, ext Bullard, Claude L (Len) wrote:

>
> Another way to view that is that it is inherently confusing
> to use http URIs as syntax walls given that overloading the
> syntax more ubiquitously used for locators confuses people.
>
> It's a built in danger.  Always was.  Always will be.
> My advice is:
>
> a) Do the right thing and put something at the location that
> settles the confusion such as pointing to the documentation
> of the namespace, and use a version attribute otherwise.

This is not practical, because (a) too many URIs already
used as namespace names do not identify namespace documents
and (b) there are those, such as myself, who have technical
issues with the whole concept/methodology of namespace
documents and thus would oppose any mandate to do so.

 From the perspective of a software agent, no presumption can
ever be made about what the URI used as a namespace name
might identify or whether the resource identified has any
relation whatsoever to the namespace -- and thus, unless
the agent has specific, reliable knowledge that the URI
identifies a namespace document, such that dereferencing it
will provide information relevant to terms grounded in that
namespace, it should not attempt to dereference any namespace
name URI. Doing so would be risky at best (and IMO improper
behavior not licensed by the specifications).

Rather, "doing the right thing" means not presuming anything
about namespace names other than they serve to syntactically
differentiate between terms.

Any relationship between a namespace, terms in that namespace,
and whatever might be identified by the namespace name URI
should be considered coincidence, and reflecting localized,
proprietary usage governed by localized, proprietary
methodologies and practices and thus inherently non-portable
and non-scalable to the global scope.

>
> b) It must be W3C policy that a namespace designer publishes
> the policy for updates to the namespace.  The form of that
> publication is left for innovation but it must be addressable.
> No this has no teeth but that is true of W3C specs in general
> and that's ok.

The problem here is that such a policy is suggestive that
the namespace is somehow equivalent to or governs the
specification/use of vocabularies, schemas, ontologies, etc.

It doesn't. A namespace is just a name-space. Period. And
how terms grounded in a given namespace are defined and
used is an entirely separate matter.

What application designers care about are the models which
are significant to the proper behavior of their solutions,
not trivial syntactic issues.

What matters is that if e.g. some version of a model
e.g. XHTML or XSLT changes, that it be clear how that
model has changed, and if new terms were added, how
those terms are to be used *for that version of the model*
and applications should focus on the versions of the
models employed -- not on the syntactic naming conventions
used to identify terms employed by various versions of
the same model, or even disparate but related models.

namespace != vocabulary
namespace != document model
namespace != ontology

As soon as folks come to understand and accept that, these
kinds of issues will (finally) go away -- and more energy
will be available for dealing with real challenges (such
as how to identify which model(s) should be applied when
some arbitrary term is encountered (and no, the solution
is not to try to dereference the namespace name of the
term...)

>
> There are three technical decisions that will bedevil
> the web architecture until the web itself is replaced:
>
> 1.  Grandfathering HTML.
> 2.  Reserving the xml: namespace.
> 3.  Using http URIs for namespace names.
>
> There are sufficient reasons for all of these except
> possibly item one because it is a social compromise,
> but we'll pay in friction for all three.  Get used to it.

True.

Still, we should reduce the friction and pain by being
clear about what is or is not licensed by the specs
rather than introducing concepts and methodologies that
further exacerbate the situation.

The introduction of the concept of "namespace document"
and the presumptions "marketed" in relation to namespace
documents and RDDL that a namespace name URI *should*
identify a namespace document just adds spin to an already
dizzy issue. And it simply distracts folks from finding
a proper solution which honors existing namespace usage
(where the namespace name URIs do not and have never
been intended to identify a namespace document) and
which focuses on the semantics of information models
rather than the syntax of term identifiers.

It's further disappointing to see so much dicussion of
namespace documents in AWWW when there is no establish
usage of such a methodology and (presumably) AWWW is
intended to reflect the distillation of experience and
wisdom arising from established and proven practices;
such that readers of AWWW may be misled into thinking
that such practices are either widespread or proven
(but that's an entirely different discussion...)

Regards,

Patrick


>
> len
>
>
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf 
> Of
> Patrick Stickler
>
> I'm afraid I don't entirely follow what you are referring to here.
> Break how? I would suspect that if applications are breaking, then
> they are making presumptions about the significance of the namespace
> that are not strictly licensed by the specs.
>
> Cheers,
>
> Patrick
>
>

Received on Thursday, 17 February 2005 08:15:50 UTC