- From: Erik Bruchez <erik@bruchez.org>
- Date: Tue, 7 Apr 2015 21:16:16 -0700
- 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:03 UTC