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