Is issue 36 critical?

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