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

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

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Fri, 10 Apr 2015 11:26:37 +0000
To: Erik Bruchez <erik@bruchez.org>, Forms WG <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Message-ID: <56C0B4CB-3DB6-4A02-8028-15D098CC8E1C@inventivegroup.com>

I think it would be quite difficult to specify an algorithm for the lax 
serialization method that behaves as the user expects. And therefore 
making it interoperable between implementations might be a challenge. As 
implementations might create a ‘better’ implementation then specified, but 
this will result in incompatibilities between implementations.

If we go for the strict version, I also have slight preference for option 
1 (dynamic error). The serialize() function[1] from xpath 3.0 also throws 
a dynamic error when any serialization error occurs.

My second choice is the empty sequence, but I think that this will make 
things more difficult when searching for errors while developing forms.

Kind Regards,
Nick Van den Bleeken                                                       
Product Evangelist
T +32 3 425 41 02
E nick.van.den.bleeken@inventivegroup.com
Inventive Designers nv
Sint-Bernardsesteenweg 552
2660 Hoboken  (Belgium)
www.inventivedesigners.com <https://www.inventivedesigners.com/>   Follow 
us on: Facebook <https://www.facebook.com/inventivedesigners> • Twitter 
<https://twitter.com/inventivedes> • YouTube 

1: http://www.w3.org/TR/xpath-functions-30/#func-serialize

On 08/04/15 06:16, "Erik Bruchez" <erik@bruchez.org> wrote:

>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
>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
>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.
>[1] http://www.w3.org/2015/03/25-forms-minutes.html


>[3] https://lists.w3.org/Archives/Public/public-forms/2015Mar/0020.html

Received on Friday, 10 April 2015 11:27:09 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 April 2015 11:27:09 UTC