- 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 UTC