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

All,

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 
<https://www.youtube.com/user/invdes>

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









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

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

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

>

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