W3C home > Mailing lists > Public > www-forms@w3.org > February 2007

Re: Chameleon schemas considerd harmful

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 5 Feb 2007 11:25:33 -0800
To: Elliotte Harold <elharo@metalab.unc.edu>
Cc: w3c-forms-request@w3.org, www-forms-editor@w3.org, www-forms@w3.org
Message-ID: <OFB57B3AA9.191AB89B-ON88257279.006A69F4-88257279.006AB6D2@ca.ibm.com>
Hi Elliotte,

On behalf the XForms working group, I am writing to inform you that the 
group elected to remove the chameleon schema feature from the 
specification.
We thank you for your feedback on this issue and trust that this 
resolution is satisfactory to you.

Best regards,
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
01/02/2007 06:13 AM

To
www-forms-editor@w3.org
cc

Subject
Chameleon schemas considerd harmful








I've just skimmed the latest draft of XForms 1.1 and chameleon schemas 
still look as evil as I first thought. This is going to cause massive 
problems for implementers of XForms processors. Consider that almost 
every XML-tool in use today from XOM to XPath 1 to DOM to XQuery to JDOM 
is based on the assumption that namespaces do not randomly change. You 
can search for or match elements by specifying a local name and a 
namespace URI. Suddenly this won't work any more. You'll need to use 
different code paths depending on the kind of document you're 
processing. This is certain to engender a confusing mass of spaghetti 
code.

For just the simplest example, consider XPath. With reliable namespaces 
we can search for all the XForms input elements like so:

//xforms:input


Now we have to do this instead:

//*[local-name()='input']

That may not even work because the host language could have an input 
element too. (HTML does.) And this is the *simplest* example I could 
think of.

Now multiply this ugliness by a thousand. That's what we're dealing with 
here.

XForms is not HTML forms and it does not need to be. Anyone moving from 
HTML forms to XForms has much larger hurdles to jump than merely 
sticking a few namespace prefixes and declarations here and there. 
Chameleon schemas are like ripping out the steering wheel of a car and 
replacing it with reins so the car will be more familiar to 
horse-and-buggy drivers, and makes about as much sense.

Can we disabuse ourselves of the fantasy that XForms is any way 
compatible with HTML forms, or that this matters? Namespaces are too 
critical a component of the XML infrastructure to abuse in this fashion. 
If namespace prefixes and declarations really are too complex for 
document authors, then XForms is too; in fact vastly more so. This 
proposal solves a trivial problem while causing massive damage 
elsewhere. Please reconsider.

-- 
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/
Received on Monday, 5 February 2007 19:27:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:08 GMT