W3C home > Mailing lists > Public > public-forms@w3.org > April 2015

ACTION-2020: Propose what to do if serialization in serialize() fails

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 7 Apr 2015 21:16:16 -0700
Message-ID: <CAAc0PEX6p4td6Myg3nuRPVfA73hsRj+t4y6h4L-SgnbtS7S1bQ@mail.gmail.com>
To: Forms WG <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
All,

This action was discussed in [this call][1] in relation to the
[`serialize()` function][2].

Alain confirmed in [this email][3] that `serialize()` can fail to
match our JSON schema.

Now, we can imagine two approaches:

1. Strict: require that the document strictly follows a schema.
2. Lax: don't require that and specify how the serialization recovers
from errors.

For example, we could say that:

- an unknown `type` attribute defaults to a `string` type
- only the value 'true" (and maybe, urgh, `yes`) mean the boolean `true`
- in the 3rd case, I am not sure!

The two approaches are valid in general I think. Clearly, the strict
option is possible. I am not sure about the lax option yet. I think it
makes sense only if we can throw pretty much any XML at it. That means
that the recovery rules must be clear. I almost think that we need to
implement the algorithm in code to see how far this would go.

If we choose the strict approach, we have the following options:

1. throw an XPath dynamic error (as if with the `error()` function)
2. return an empty sequence
3. return an error document
4. dispatch an event

In XPath 2, options #1 and #2 are natural. One issue with #1 is that
there is no try/catch in XPath 2 (there is in XQuery though). This is
not necessarily a showstopper though, as we specify what happens with
XPath errors and action errors now.

Option #2 has the drawback of lacking any specific error information.

Option #3 is possible but means that the function can return either a
string or a node, and I don't like that as XPath doesn't have union
types.

Option #4 is my least favorite, because dispatching an event *while*
executing an expression is a side effect, and in general we don't want
functions to have side effects.

Neither XPath 2 nor XForms actions have a mechanism to handle errors
and then recover. The closest, again, would be something like a
try/catch.

I think that the best solution at this point, if we decide that the
function can fail, is option #1: throw an XPath dynamic error. We can
clarify the spec text if needed.

So the next steps are:

1. Decide whether we want the strict or lax approach for `serialize()`.
2. If we go for the strict option, decide whether we are ok with the
dynamic error option.

Thoughts?

-Erik

[1] http://www.w3.org/2015/03/25-forms-minutes.html
[2] https://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_serialize.28.29_Function
[3] https://lists.w3.org/Archives/Public/public-forms/2015Mar/0020.html
Received on Wednesday, 8 April 2015 04:17:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 April 2015 04:17:04 UTC