Re: ACTION-1868 - Bruchez to summarize problems with error handling and three options for variable type handling

All,

I have now completed the changes to error handling, minus a few questions below.

Here is the main diff:

http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XForms_2.0&diff=3880&oldid=3868

I haven't fully removed the "old" `xforms-compute-exception` and
`xforms-binding-exception` events, and they remain in the following
places:

1. Remaining `xforms-compute-exception`:

- `functions` attribute
- `xforms-recalculate`
  - circular dependencies
  - "Any expression violating any Binding Expression Constraint causes
an exception"

The `functions` case is probably reasonable, because the whole point
of this is to cause the XForms Processor to crash and burn if a
function is missing (so the opposite of error recovery).

Speaking of which, the spec was inconsistent here. The text said:

    "The names of any such extension functions must be declared in
attribute functions on element model"

But the following note said:

    "Failure by authors to declare extension functions"

It can't be a "must" if then we allow for the case where it doesn't
happen. So I changed the "must" to "should".

The `xforms-recalculate` case, however, is unclear to me and I have
added an editorial note. I have two related questions:

- First, does it make sense to recover in case of circular
dependencies, and if so how?

- Second, the spec talks about "Binding Expression Constraint" for
"calculate, relevant, readonly, or required", but this is the only
place in the spec where this sequence of words appears! There is a
mention of "binding restriction" but for controls only. I am tempted
to consider this a recoverable case, or maybe even remove the two
places where references to "Binding Expression Constraint" appear.

2. Remaining `xforms-binding-exception`:

- automatic instance creation upon `xforms-model-construct-done`
- XForms full processor conformance, for missing group/switch/repeat modules!

The first case could be made recoverable, I guess. I am not sure
anybody implements this feature, by the way.

The second case is for something entirely new to me: it seems weird to
dispatch a `xforms-binding-exception` for unrecognized/unimplemented
elements! Also, I am surprised that the "full" profile doesn't require
(they are a "should") groups, switch, or repeats, and consider the
case where they might not be supported. This seems not to qualify for
"full" XForms to me!

I updated the description of the two exception events to reflect their
current use in the spec.

Finally, I also fixed an event name in the XPath Expressions Module:

http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XPath_Expressions_Module&diff=3881&oldid=3867

To summarize:

- I am now "code complete" as far as the changes to error handling are
concerned.
- However there are a few open questions wrt the old *-exception events.

Feedback welcome.

-Erik

Received on Wednesday, 27 November 2013 06:31:18 UTC