Re: Significant W3C Confusion over Namespace Meaning and Policy

John Boyer wrote:


> The URI is certainly more than just a pointer to a container;
> it is intrinsically attached to each name in that container.  
> The URI provides the distinguishing component in the full expanded name 
> of an element or attribute separates that element or attribute from others 
> that have the same local name.  The direct association of the URI and
> each name is pervasive, not just in the namespaces rec, but 
> also in xpath, infoset, schema and so forth.  To say that 
> the URI is meant to be attached to the actual names in every
> case except this one is a reach beyond the bounds of reasonable
> doubt at what the one sentence in the definition could possibly 
> mean.  It implies a hidden inconsistency. Heck even the grammar
> error in the definition leads one to believe they're talking about
> the names and not the container.

You're reaching. That's just not a big problem; not nearly as big as the 
practical problems of changing the namespace for every iteration of the 
vocabulary.

Theoretically, think of it this way. "Harold" is intimately attached to 
the name "Elliotte" and a few other names as well: Beth, Edward, 
Elizabeth, etc. But by itself "Harold" identifies the family, not the 
individual members of the family. It seems perfectly reasonable to me to 
treat namespace URIs the same way: as a sort of last name for individual 
members of a mutable collection, and as a name for the collection.


> How does a software module know, for example, which of two
> schema documents with which to load the parser if they have
> the same target namespaces but describe different sets of
> vocabulary?  

You're assuming there's only one schema per namespace. That is neither 
true in theory or practice. The same namespace can and often does have 
multiple schemas. I may not apply the same schema to a namespace that 
you use. That's perfectly OK.


> How is the meaning of a block of XML protected by a digital 
> signature when the meaning can be changed without changing
> the serialization?
> 
> What happens when an XSLT stops working in a subtle way
> because the schema for the namespace changed to make a
> required element optional or vice versa? What if the 
> problem doesn't get noticed until 10,000 peoples' savings 
> disappear on an otherwise sunny afternoon?

There is no "the scheme for the namespace". There is only the schema I 
choose to apply in my system. You may have a different schema for the 
same namespace. If you have that much faith in the ability of schemas to 
prevent problems. I don't think I have that much faith in your systems.

> Clearly there are also problems with not versioning with
> namespaces. Moreover, other than the claim that it is very 
> problematic to use namespaces in version control, what's 
> your half decade's evidence that it is?

This was hashed out extensively some years ago when XHTML tried to use 
multiple namespaces for multiple schemas. It rapidly became apparent 
that wasn't going to work.


> In fact, the namespace change that occurs for every version
> of our XFDL language is the major facilitator in helping us to 
> ensure backwards compatibility while evolving our implementations
> to add new features. If you have a version 6 form, it will
> behave identically when you run it in the version 7 processor.  
> So, you can deploy the upgraded processor to get the new 
> functionality for new applications without worrying about 
> breaking the existing forms applications, which can then be 
> upgraded only as the need arises.

It sounds like you have incredibly tight coupling between the processor 
and the documents format, and expect you can upgrade them in lockstep. 
This can sometimes be made to work in internal systems, but it's 
hopeless in the open world of the Internet where schemas ear not 
trustworthy, documents are not valid, and everyone upgrades to different 
versions of different software at different times with different bugs.

> And why would this stop the processors in a particular
> domain from attempting to process documents of a higher
> version (albeit with reduced or erroneous functionality)?

You assume we want to stop that. It's becoming apparent that you adhere 
to the classic fallacy that it's possible to lock everything down, 
require everyone to process documents that mean certain things in 
certain ways, and agree in advance on all details. That's far too 
restrictive to have much hope of working on the Internet. The question 
to ask of a document is not whether it adheres to this schema or that 
schema, but whether it contains the information you need to get your job 
done.

> Nope, just can't figure out why some would consider wrapping 
> antigen software around this idea when it's so much easier to 
> just wrap a function around the check of the namespace URI.

Because ultimately checking the namespace URI doesn't prove as much as 
you seem to think it proves.


-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

Received on Friday, 11 February 2005 01:43:04 UTC