W3C home > Mailing lists > Public > www-tag@w3.org > February 2005

Re: Significant W3C Confusion over Namespace Meaning and Policy

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 17 Feb 2005 10:59:33 +0200
Message-Id: <aff24210f87a04780b3061e95d280877@nokia.com>
Cc: www-tag@w3.org, "'Harry Halpin'" <hhalpin@ibiblio.org>
To: "ext Bullard, Claude L (Len)" <len.bullard@intergraph.com>

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

> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf 
> Of
> Harry Halpin
>> While I agree that Henry is technically correct (technically as in 
>> "read
>> the specification"), this giant perma-thread clearly shows that there 
>> are
>> simply problems in keeping track of versioning with namespaces.
> It's just a bit weirder if one tries to solve this with one stroke but
> it points to the problem of static plots for dynamic system motions.
> An instance has to conform to multiple dynamic namespaces with
> multiple authorities with different policies.  Syncing those
> is probabilistic at best but impossible without controls.
> One is the xml:namespace which has implications to a universally shared
> processor TYPE, the xml processor.  Depending on the sharing of
> semantics, some namespace niches have more importance (reach) than
> others and should have stronger controls.   This is a fairly classic
> cybernetic control problem of degrees and connection strength.  It
> is soluable if the namespace authority provides the control.  Then
> it is a question of control types.

IMO, the addition of xml:id warrants a new (minor) version increment
of the XML model.

Applications which support previous versions should disregard terms
not specified as employed by the version they utilize; and applications
which are updated to support the new version will utilize the new
terms such as xml:id appropriately.

Applications producing content utilizing the new version of XML,
(potentially) employing the new terms, such as xml:id, will
indicate this via the <?xml ?> PI.

Thus, it's clear which version of XML is relevant to interpreting
the content, and the fact that subsequent versions of XML introduce
new terms grounded in the xml: namespace is irrelevant to XML
processors -- insofar as the function of the namespace itself
is concerned.

> It appears to weaken the case for non-validating systems because
> there is at least one namespace that you always want to validate,
> the xml namespace (depending on rate of change) and possibly others.

But this presumes that the xml: namespace equates to a particular
version of the XML model, which it doesn't. Rather, you want to
validate against a particular version of XML, not the namespace.

> You could use a publish/subscribe model: if the authority makes a 
> change,
> it broadcasts that to all depending nodes (update on notify). So
> it is something like RSS/RDDL.
> That feels rube goldbergian, so don't take that on face value.
> A version att is simpler with schemas at the URI location.

Why not just identify particular versions of particular models
with URIs, providing representations of those models via those
URIs, and specify with each content instance the model(s)
relevant to interpretation of that content?

Most (maybe all) of the pieces of a solution exist. If folks would
get away from the seeming fixation with namespaces and namespace
documents, we might actually see a solution emerge.


Received on Thursday, 17 February 2005 09:06:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:07 UTC