Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 16, 2005, at 23:09, ext David Orchard wrote:

>
> I think that a namespace owner can specify exactly what they mean a
> namespace to mean wrt the names in the space.  The owner has at least 3
> options:
>
> 1. Say the names in the ns are fixed and immutable
> 2. Say nothing about the names
> 3. Say the names in the ns are mutable.

Well, this is more about how a given namespace owner
chooses to utilize a namespace, rather than what
they mean a namespace to mean.

I.e. best to consider a given namespace infinite -- to already
include all possible names that could be grounded in that
namespace -- and to focus on the models which specify *which*
terms are relevant to the application of that model, irregardless
of the syntax of the identifiers.

Restriction of the right to utilize terms from a given
namespace to the owner of the namespace is really a social,
not a technical, issue; such that for that infinite space
of names, the owner reserves the right to specify how
any presently unused terms might be used in the future.
But what counts is not which terms are in use at a given
time but in which *models* they are used, and *how*, and
one cannot determine anything useful simply by focusing
on the namespace itself irrespective of those models.

If applications are focusing on the semantics of the
models by which content is to be interpreted, rather than
on the syntax of the identifiers used to identify terms
employed by those models, then "changes" to namespaces
should be entirely irrelevant.


>
> In option #3, it would seem a good thing for the ns author to say under
> what conditions the names can change, from "backwards compatible"
> changes, where the meaning of bc is defined by the ns owner to even
> "completely incompatible" changes.
>

But this is specific to how the terms are used -- i.e. the model,
the schema, the ontology -- not the namespace.

Yes, the author of a given model *should* specify how changes
to the model affect backwards compatibility, and at what point
one version of the model becomes incompatible with applications
based on a previous version.

But that has nothing to do with namespaces.

> Option #2 carries the risk that 50% of software will assume #1 and 50%
> will assume #3, and then they will be faced with a tough choice when
> they want to version.  Does the author retrofit option #1 on to v1, and
> then lose the benefits of option #3, or does the author retrofit #3 on
> to v2, and perhaps breaking software that made assumption of option #1.
>
> Seems to me yet another case of where the language designer needs to do
> up front planning and thinking in order to prevent versioning problems,
> sometimes called architecture...

Quite. The problem at hand is that too many folks seem to be
mistakenly equating namespaces with higher architectural
levels.

Patrick


> Cheers,
> Dave
>
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
> Of
>> paul.downey@bt.com
>> Sent: Wednesday, February 16, 2005 6:32 AM
>> To: dareo@microsoft.com; patrick.stickler@nokia.com;
> Norman.Walsh@Sun.COM
>> Cc: www-tag@w3.org
>> Subject: RE: Significant W3C Confusion over Namespace Meaning and
> Policy
>>
>>
>> Dare wrote:
>>
>>> Then what does the namespace name identify? XML namespaces
>>> seem to grow more and more useless by each passing day.
>>
>> A namespace provides a means of ownership, and doesn't, IMO,
>> identify  a strict vocabulary frozen at some point in time.
>>
>> This demarcation still has some real value, not least to prevent
>> clashes of names inserted into a combined document from different
>> origins.
>>
>> Paul
>>
>
>

Received on Thursday, 17 February 2005 08:59:28 UTC