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

Hi guys,

I should clarify that my question about the ID space resolution was 
prompted by these two statements in Erik's write-up

Suggests ID space within instance:
"#5 is a way to support both #2. #3 and #4 at the same time."

Suggests ID space outside of instance:
"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. "

Seems better for the serialize() function parameter to reference only 
instance data, as suggested, and if so, then option 2 referencing an 
element seems best. Option 3 requires the user to put @* on the end of 
whatever element they were going to put the attributes on anyway. Sure it 
gives them flexibility to put the attributes all over the place and union 
them together, but who needs it.  Also agreed option 2 can do options 4 
and 5 with the id() function.

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




From:   Erik Bruchez <erik@bruchez.org>
To:     Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>, 
Cc:     John Boyer/CanWest/IBM@IBMCA, Public Forms <public-forms@w3.org>, 
"public-xformsusers@w3.org" <public-xformsusers@w3.org>, Steven Pemberton 
<Steven.Pemberton@cwi.nl>
Date:   17/04/2013 09:05 AM
Subject:        Re: Concerns about format token parameter on serialize() 
and parse() functions
Sent by:        ebruchez@gmail.com



All,

We talked about this during the call. We have at least one other case of 
an XPath function taking an id outside of instance data, namely the 
xf:case() function, and we have the proposed xf:bind() function. In our 
own implementation, we also have other functions to search for example for 
control bindings by id, etc.

We also have the @schema attribute which can search for elements outside 
the model:

"The schema list may include URI fragments referring to elements located 
outside the current model elsewhere in the containing document; e.g. 
"#myschema". xs:schema elements located inside the current model need not 
be listed."

So yes the id() function specifically looks for elements in instance data, 
but there is nothing wrong with looking for "stuff" outside of instance 
data from an XPath function based on an id passed as a string. And I say 
"stuff" because here we are not making anything outside of instance data 
part of an XPath data model: we just refer to an element in the document 
by id, and it's up to the function to do something with it. In this case, 
getting name/value pairs from its attributes (in the same way that the 
xf:case() function has to find a control, and somehow get access to a 
property of that control).

This said, it seems based on today's discussion that we would prefer 
having just one version of the function which takes an element, as that 
makes the signature of the function simpler and that covers all the use 
cases, although it might require you to create an extra instance in some 
cases. If we stay with this decision, that means that we don't have an id 
resolution question here.

-Erik


On Wed, Apr 17, 2013 at 8:20 AM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:
John, 

Sorry, it looks like I didn't read Erik's e-mail carefully, and just ready 
what I wanted to read…. 

That said, I don't like referring elements outside XForms instances from 
an XPath expression. 

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




On 17 Apr 2013, at 17:15, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com>
 wrote:

Hi John, 

In all those proposed solutions the configuration would reside in an 
XForms instance. And *not* in the host document outside an instance.

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


<image001.png><image002.png><image003.png> 

On 17 Apr 2013, at 16:20, John Boyer <boyerj@ca.ibm.com> wrote:

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







Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer