- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Thu, 10 Feb 2005 20:43:00 -0500
- To: John Boyer <JBoyer@PureEdge.com>
- CC: Robin Berjon <robin.berjon@expway.fr>, www-tag@w3.org
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