Re: Chameleon schema considered harmful

Speaking only on behalf of myself, I sincerely hope that the notion of 
chameleon namespace is not ever used for anything other than importing 
XForms into XHTML.

Users of all other host languages seem to have no problem whatsoever 
understanding the need to namespace qualify tags from different 
vocabularies.

However, the longer history of the web has rather boxed us into a corner. 
There's just too much push-back from the web community about the use of 
namespace qualification on elements in HTML.  I am told that there are 
just too many picky details to contend with that stand as significant 
adoption obstacles to our attempts to upgrade the HTML forms capability.

No matter how good XForms is, as soon as you say that the author must 
start to use some manner of namespace qualification, whether by default or 
by prefix, the answer becomes "Ah, then over my dead body is it going to 
be the next generation of web forms."

So, you are not necessarily fighting a reasonable technical problem, which 
is why the use of reason and technical prowess is failing to produce an 
explanation for you about why this is happening.

Personally, I think that the effort to make the XForms schema 
"chameleonable" is maybe a bit over-engineered and leads to the 
misunderstanding that every host language should do it.  What we really 
needed to solve the ease-of-authoring and ease-of-content-migration 
problems was for XHTML to say of XForms "like that, only here".  In other 
words, to import by spec parallelism.  Of course, maintaining two parallel 
schemas for the same tag set is a recipe for error, so the 
parameterization does help with that.

In general, you're right that there would be no need of namespaces if the 
world had the time to rationalize every pair of vocublaries before using 
them together.  Namespaces solves that, but it also does not forbid 
vocabulary authors from rationalizing their tagsets on a one-off basis. 
But, for all the technical reasons you point out and more, it is unlikely 
to be successful if done very often.  However, the extreme priority on 
ease-of-authoring/ease-of-content-migration looks specific to the HTML 
community, which had significant momentum even before XML and namespaces 
existed.  Further, since rationalizing the HTML and XForms vocabularies 
required adjustments to both, my hope is that this use of chameleon 
namespace will not get much use beyond HTML.

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Elliotte Harold <elharo@metalab.unc.edu> 
Sent by: w3c-forms-request@w3.org
10/25/2006 01:19 PM

To
www-forms-editor@w3.org
cc

Subject
Chameleon schema considered harmful








I want to raise a formal objection to the whole idea of chameleon 
namespaces in XForms 1.1. This is not how namespaces are designed to 
work and it's going to cause massive problems for anyone writing any 
sort of software to process XForms, whether it's DOM, SAX. XSLT, XPath, 
or almost anything else.

XForms elements should be able to be recognized by their namespace 
alone. I should not have to care about the host language in which 
they're embedded.

If we're going to go changing the namespace for every host language that 
comes along, we might as well not have namespaces in the first place.

-- 
Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/