Re: Is issue 36 critical?

John & all,

 > 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 am fine deferring to 1.2/2.0, but I would like the issues to be
addressed in a future version.

 > 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).

I think it is inappropriate. The whole point of my comments were to
point out that out specification is inconsistent and confusing in this

The confusion arises from inconsistencies or the lack of recognizable
principles or patterns. For form authors and implementors, consistency
is very important to facilitate the learning curve and the
maintenance. If you call something "binding exception", it better
relate to a binding or it is misnamed. I really don't see a good way
around that.

I believe that "binding" has a very clear meaning in XForms, although
it is not necessarily that clearly explained in the spec.

Beyond that, there is no need to call other expressions like @value
expressions "bindings" or "pseudo-bindings". XSLT and other such
specifications do not need this concept, and neither do we. Those are
just XPath expressions.

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

First, I am not necessarily requesting this. This was one of the
possible options.

The idea is that if you are going to dispatch events that stop
processing entirely, it would be better for the form author and user
to do so as early as possible. Otherwise you may start filling out a
form, spend 1/2 hour on it, and then upon submission get an
irremediably broken form with an error that could be detected way
ahead of time.

I am here particularly referring to XPath exceptions on actions like

So I was proposing that a possible solution was to request that static
analysis of all XPath exceptions would be done during XForms
initialization for author and user convenience.

This is what XSLT does, by the way: a stylesheet is first constructed
and the document and expressions are syntactically checked. Static
errors are raised during that phase. Then when actually running the
stylesheet, you may get dynamic errors. This is not a foreign concept
in programming.

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

That is an option. But we have to be aware that we lose an
interoperable capability of early error detection with this
approach. I considered this in my initial message and this raises the
issue that maybe none of the errors occurring at a later time should
completely stop processing. Why, for example, would setvalue/@ref
raise a binding exception that stop processing, but not
setvalue/@value? There would be no good reason for something like this.

 > Can you please let us know if there is any part of the above that
 > you cannot live with for issue 36.

Well, pretty much everything ;-) I think that the implications of my
original message have to be understood, and based on what I am reading
here this does not appear to be the case. However, as I said, I can
accept deferring these issues to post-1.1.


Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Thursday, 18 October 2007 21:03:15 UTC