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

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  

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)"/>



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, 28 November 2012 17:35:44 UTC