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

John,

Thanks for the feedback. I think we'll go this way. In addition, this is
closer from the XPath 3 serialize() function which just takes an element.

I have a new action item to review the XPath 3 serialize() function in more
depth to see if we are missing something with that funky
output:serialization-parameters element (which it turns out uses nested
elements instead of attributes).

-Erik


On Wed, Apr 17, 2013 at 9:57 AM, John Boyer <boyerj@ca.ibm.com> wrote:

> 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*<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* <%2B32%203%20425%2041%2002>
> Office fax: *+32 3 821 01 71* <%2B32%203%20821%2001%2071>*
> **nick.van.den.bleeken@inventivegroup.com*<nick.van.den.bleeken@inventivegroup.com>
> *
> **www.inventivedesigners.com* <http://www.inventivedesigners.com/>
>
>
>
>
> On 17 Apr 2013, at 17:15, Nick Van den Bleeken <*
> Nick.Van.den.Bleeken@inventivegroup.com*<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* <%2B32%203%20425%2041%2002>
> Office fax: *+32 3 821 01 71* <%2B32%203%20821%2001%2071>*
> **nick.van.den.bleeken@inventivegroup.com*<nick.van.den.bleeken@inventivegroup.com>
> *
> **www.inventivedesigners.com* <http://www.inventivedesigners.com/>
>
>
> <image001.png><image002.png><image003.png>
>
> On 17 Apr 2013, at 16:20, John Boyer <*boyerj@ca.ibm.com*<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* <boyerj@ca.ibm.com>
>
>
>
>
> From:        Nick Van den Bleeken <*
> Nick.Van.den.Bleeken@inventivegroup.com*<Nick.Van.den.Bleeken@inventivegroup.com>
> >
> To:        Erik Bruchez <*erik@bruchez.org* <erik@bruchez.org>>,
> Cc:        Steven Pemberton <*Steven.Pemberton@cwi.nl*<Steven.Pemberton@cwi.nl>>,
> Public Forms <*public-forms@w3.org* <public-forms@w3.org>>, "*
> public-xformsusers@w3.org* <public-xformsusers@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*<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*<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* <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*<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* <%2B32%203%20425%2041%2002>
> >>> Office fax: *+32 3 821 01 71* <%2B32%203%20821%2001%2071>
> >>> *nick.van.den.bleeken@inventivegroup.com*<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
> *<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
> *<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*<http://www.w3.org/TR/xpath-functions-30/#func-serialize>
> >>> 4: *http://www.w3.org/TR/xpath-functions-30/#func-parse-xml*<http://www.w3.org/TR/xpath-functions-30/#func-parse-xml>
> >>> 5: *http://www.w3.org/TR/xpath-functions-30/#func-parse-xml-fragment*<http://www.w3.org/TR/xpath-functions-30/#func-parse-xml-fragment>
> >>>
> >>> ________________________________
> >>>
> >>> Inventive Designers' Email Disclaimer:
> >>> *http://www.inventivedesigners.com/email-disclaimer*<http://www.inventivedesigners.com/email-disclaimer>
> >>
> >>
> >
> >
>
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:*
> **http://www.inventivedesigners.com/email-disclaimer*<http://www.inventivedesigners.com/email-disclaimer>
>
>
>
>
>
>  ------------------------------
>
> Inventive Designers' Email Disclaimer:*
> **http://www.inventivedesigners.com/email-disclaimer*<http://www.inventivedesigners.com/email-disclaimer>
>
>