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

Hi guys,

Is there a reason why serialize() couldn't be responsive to both #2 and 
#3. If you pass it an element, it uses the attributes of the element, if 
you pass the attributes, it uses them.

It's not clear to me that #4 and #5 are quite as general because the ID 
space of the document is different than the ID space of the instance that 
contains the context node where the function is being evaluated (if any). 
Can you explain how XForms would know where to look for the identified 
element?

Thanks,
John M. Boyer, Ph.D.
IBM Distinguished Engineer & IBM Master Inventor
@johnboyerphd | boyerj@ca.ibm.com




From:   Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
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>
Date:   17/04/2013 05:47 AM
Subject:        Re: Concerns about format token parameter on serialize() 
and  parse() functions



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