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

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
>