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

Re: Concerns about format token parameter on serialize() and parse() functions

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Wed, 17 Apr 2013 12:45:42 +0000
To: Erik Bruchez <erik@bruchez.org>
CC: Steven Pemberton <Steven.Pemberton@cwi.nl>, Public Forms <public-forms@w3.org>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Message-ID: <CB044B48-6DC3-4B38-BCCC-15B64DF75750@inventivegroup.com>
First of all I would like to say that it is a good description of the problem an possible solutions ;)

I don't have a strong opinion about choosing one of the options #2 to #5. But have a slight preference to option #2.

Even knowing that option #3 is more general, because if you choose this option you can easily convert from options #2, #4 and #5 to option #2 (e.g.: $node/@* and id($id)/@*)

Best,

Nick Van den Bleeken
On 17 Apr 2013, at 09:18, Erik Bruchez <erik@bruchez.org>
 wrote:

> All,
>
> In response to this proposal, I got the following action item last week:
>
> ACTION-1942 - Send his proposal about passing an element to the
> serialise and parse functions for the format options and only look at
> the attributes on the element (we will ignore the element name)
>
> First, my understanding of the issue is that:
>
> - these functions need a fairly large number of parameters
> - future serialization options can be conceived of at a later time
> - a list of tokens is not enough (we need name/value pairs)
> - it's not practical to pass these parameters as regular function
> parameter in XPath (because parameters must be passed by position)
>
> In general, with other languages, there would be ways to solve this, such as:
>
> 1. Passing a hash map such as a JavaScript object or an XSLT 3 map.
> 2. Having named and default parameters, as in Scala.
>
> But we don't have any of these features in XPath 2. This means that we
> are looking for a workaround to pass all these parameters as a single
> XPath function parameter, directly or indirectly.
>
> The obvious way is to refer to an XML element, since an elements's
> attributes form a nice name -> value mapping. Note that it doesn't
> matter what the element *name* is, just what its attributes are, since
> we are interested in the name/value pairs. So referring to the element
> is just a way to refer to its attributes. So alternatively, we could
> also pass a sequence of attributes directly.
>
> Steven's proposal is along these lines. However I have an issue with
> the use of xf:submission, namely that the parameters of submission
> which are useful to serialize() are a subset of what xf:submission
> requires.
>
> For example, xf:submission requires specifying an action/resource and
> method, neither of which are needed to configure XML serialization.
> You would either have to:
>
> - put dummy attributes on that xf:submission
> - or change xf:submission to make these optional
>
> Either way you end up with a submission which probably cannot be used
> as such (with the send action).
>
> Since again we only need name/value pairs, I think there is not a
> super compelling case for requiring reuse of xf:submission anyway.
>
> I think the options below would be more general and flexible and easy
> to specify:
>
> 1. We can point directly to an element or attributes. In XForms, this
> typically means that the element or attributes are in instance data.
>
> 2. We can pass the id of an element. In XForms, this typically means
> that the element is not in instance data, but is external, for example
> under the xf:model element.
>
> These options are not exclusive.
>
> XPath 3's serialize() function [1], by the way, uses a reference to an
> element output:serialization-parameters, which I think is pretty
> terrible. The only benefit of doing what XPath 3 does here would be
> compatibility with it. Is it a good idea?
>
> So we could define one or several of the following:
>
> 1. serialize($arg as item()*) (: use default serialization params :)
>
> 2. serialize($arg as item()*, $params as element()) (: point to
> element and use its attributes :)
>
> 3. serialize($arg as item()*, $params as attribute()*) (: point to attributes :)
>
> 4. serialize($arg as item()*, $id as xs:string) (: point to element by
> id and use its attributes :)
>
> 5. serialize($arg as item()*, $id as item()) (: point to element
> either directly or by id :)
>
> There is no overloading with XPath functions so we would have to
> choose which of #2 to #5 we would like to have. #5 is a way to support
> both #2. #3 and #4 at the same time.
>
> Note that, if the name/values needed happen to coincide with some on
> xf:submission, then form #4 above could point to an existing
> xf:submission. In short that would also cover Steven's proposal, but
> could do more.
>
> I think we do need a version of the function pointing to instance data
> so that we can support dynamic serialization params. Now do we also
> need the ability to refer to an element outside of instance data?
> Feedback welcome.
>
> -Erik
>
> [1] http://www.w3.org/TR/xpath-functions-30/#func-serialize
>
> On Wed, Nov 28, 2012 at 9:27 AM, Steven Pemberton
> <Steven.Pemberton@cwi.nl> wrote:
>> We discussed this at the call today.
>>
>> Simple example of the use of the serialize function:
>>
>>        <bind ref="text1" calculate="xf:serialize(../node)"/>
>>
>> More advanced uses:
>>
>>        <bind ref="text2" calculate="xf:serialize(../node, json)"/>
>>        <bind ref="text3" calculate="xf:serialize(../node, xml validate
>> relevant)"/>
>>
>> The point here is to mirror the parts of the <submission/> element that are
>> needed to serialize a value.
>>
>> However, Nick's worry is that a simple list of format tokens as in the
>> second and third examples is not future-proof should there ever be
>> non-boolean parameters.
>>
>> The idea that arose in the call was just to use a <submission/> element to
>> supply the paramers, since we already have that mechanism, and authors will
>> already know it:
>>
>>        <submission id="fmt1" serialization="application/json"/>
>>        <submission id="fmt2" serialization="application/xml" version="1.1"
>> separator=";" validate="true"/>
>> ...
>>        <bind ref="text1" calculate="xf:serialize(../node)"/>
>>        <bind ref="text2" calculate="xf:serialize(../node, fmt1)"/>
>>        <bind ref="text3" calculate="xf:serialize(../node, fmt2)"/>
>>
>> Comments?
>>
>> Steven
>>
>>
>> On Wed, 21 Nov 2012 09:54:03 +0100, Nick Van den Bleeken
>> <Nick.Van.den.Bleeken@inventivegroup.com> wrote:
>>
>>> All,
>>>
>>> I'm a bit concerned about the format parameter on serialize() [1] and
>>> parse()[2] functions, because I think that the format token only allows
>>> boolean properties. And on the submission element and xslt output options
>>> you have properties that take other type of values. For example version,
>>> cdata-section-elements and includenamespaceprefixes.
>>>
>>> We could decide that the serialize() and parse() functions are only for
>>> the simple things and that we will depend on the serialise()[3],
>>> parse-xml()[4], parse-xml-fragment()[5] functions in 'XPath and XQuery
>>> Functions and Operators 3.0' for the more advanced stuff.
>>>
>>> What is your opinion about this?
>>>
>>> Kind regards,
>>>
>>> Nick Van den Bleeken
>>> R&D Manager
>>>
>>> Phone: +32 3 425 41 02
>>> Office fax: +32 3 821 01 71
>>> nick.van.den.bleeken@inventivegroup.com
>>> www.inventivedesigners.com
>>>
>>>
>>> 1:
>>> http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_serialize.28.29_Function
>>> 2:
>>> http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_parse.28.29_Function
>>> 3: http://www.w3.org/TR/xpath-functions-30/#func-serialize
>>> 4: http://www.w3.org/TR/xpath-functions-30/#func-parse-xml
>>> 5: http://www.w3.org/TR/xpath-functions-30/#func-parse-xml-fragment
>>>
>>> ________________________________
>>>
>>> Inventive Designers' Email Disclaimer:
>>> http://www.inventivedesigners.com/email-disclaimer
>>
>>
>
>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Received on Wednesday, 17 April 2013 12:46:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:08 UTC