- From: John Boyer <boyerj@ca.ibm.com>
- Date: Thu, 18 Oct 2007 02:05:36 -0700
- To: ebruchez@orbeon.com
- Cc: Forms WG (new) <public-forms@w3.org>
- Message-ID: <OF9E69F849.4816B323-ON88257378.00300F24-88257378.0031F5A8@ca.ibm.com>
Hi Erik, we seem to have two kinds of exceptions related to referencing nodes using xpaths. They are called xforms-binding-exception and xforms-compute-exception. In hindsight, we should have just had xforms-xpath-exception, and those other cases where xforms-binding-exception is used should have actually issued a better named exception. But hindsight being what it is, I am wondering if you can live without further modifications of the exception system in XForms 1.1 and defer much of this issue to 1.2/2.0? I did use the term "computed expression" now in 7.6 to exactly indicate those Xpaths that would produce a compute exception rather than a binding exception. Also, the concern you have about identifying all the static errors should be addressed in the open issue of the same nature raised by Michael. But you raised a number of other issues that seem either deferable or unnecessary. For example, the fact that attributes like "at" and "value" are not, strictly speaking, defined to be bindings does not mean it is wholly inappropriate to raise an xforms-binding-exception if they fail. They are, in a sense, bindings of some sort or another. One might use the term "ephemeral binding" for "at" and possibly "Special UI Binding" for value on output (if really pushed to solve this). Another example is that you request that we define the fact that all xpaths of the whole document are checked on initialization. I have no idea why you want this or what purpose it serves, but the spec is already pretty clear on when xpaths are evaluated for the first time. Those in bind elements are first evaluated during model construction, UI bindings and other UI xpaths are first evaluated when the associated UI controls are first created, much of which happens in UI construction after model construct done. I say "much" because implementations are free and in fact encouraged not to read the UI inside of non-selected switch cases, non-relevant groups and empty repeats. I think it is quite a bad idea to require them to do so, and so you will only see XPath exceptions later in processing. The same idea applies to actions, which are only executed when needed (e.g. when the event they handle actually occurs). Finally, yes I believe it is appropriate to issue a binding exception even for things like setvalue if the xpath is *fundamentally* busted in a way that means it will *never* run correctly. Can you please let us know if there is any part of the above that you cannot live with for issue 36. Thank you, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Received on Thursday, 18 October 2007 09:06:10 UTC