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

Chameleon schemas considerd harmful

From: Elliotte Harold <elharo@metalab.unc.edu>
Date: Tue, 02 Jan 2007 09:13:28 -0500
Message-ID: <459A6888.6040107@metalab.unc.edu>
To: www-forms-editor@w3.org

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:


Now we have to do this instead:


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 

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!
Received on Tuesday, 2 January 2007 14:20:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:11 UTC