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


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

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.



On Wed, Nov 28, 2012 at 9:27 AM, Steven Pemberton
<> 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
> <> 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
>> 1:
>> 2:
>> 3:
>> 4:
>> 5:
>> ________________________________
>> Inventive Designers' Email Disclaimer:

Received on Wednesday, 17 April 2013 07:19:05 UTC