- From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- Date: Thu, 3 Nov 2011 07:39:14 +0000
- To: John Boyer <boyerj@ca.ibm.com>
- CC: "<public-forms@w3.org>" <public-forms@w3.org>
- Message-ID: <2C116FFA-79A9-4B01-9185-05FAF95FA111@inventivegroup.com>
Hi John, Thank you for your reply One reason I am asking about use cases is because the functions don't, in my opinion, contribute as much to readability as I'd like, and at the same time it seems like they contribute implementation complexity. Examples which create an XML fragment that is known at form design time Markup with functions: <xforms:insert context="section" origin="xf:element('value', (xf:attribute('id', 'my-value'), 'John'))"/> Markup with parse function: <xforms:insert context="section" origin="xf:parse('<value id=&qout;my-value">John</value>')"/> In practice the functions are mostly used to create XML content that is based on content that is entered by the person who is filling in the form: Markup with functions: <xforms:insert context="section" origin="xf:element('value', (xf:attribute('id', xf:context()/id), xf:context()/name))"/> Markup with parse function: <xforms:insert context="section" origin="xf:parse(concat('<value id=&qout;', xf:escape-xml(xf:context()/id),'">', xf:escape-xml(xf:context()/name),'</value>'))"/> The xf:escape-xml function is needed to escape special characters line quotes, less then, … Personally I find the markup with the functions more readable, and simpler to use, then the markup with the parse function, but this is probable a personal preference… It's a bit bizarre to contruct and XML tree out of a long series of function calls, especially when you realize that function parameters tend to get evaluated before invoking the function, so technically a larger XML gets assembled from the bottom up. John can you elaborate a bit more what the problem is with constructing an XML tree bottom up? Moreover, parse() has other uses that element() and attribute() just don't solve. In my opinion the functions are complimentary. The markup to create XML is simpler (in my opinion, but this is of course debatable). But the attribute function allows you to create stand alone attributes that can be used in for example the insert function, with the parse function you can't create a standalone attribute to insert, because this isn't valid XML. Kind regards, Nick Van den Bleeken R&D Manager Phone: +32 3 821 01 70 Office fax: +32 3 821 01 71 nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com> www.inventivedesigners.com [cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110] On 02 Nov 2011, at 23:15, John Boyer wrote: Hi Nick, One reason I am asking about use cases is because the functions don't, in my opinion, contribute as much to readability as I'd like, and at the same time it seems like they contribute implementation complexity. It's a bit bizarre to contruct and XML tree out of a long series of function calls, especially when you realize that function parameters tend to get evaluated before invoking the function, so technically a larger XML gets assembled from the bottom up. I just started wondering if we really needed to create attributes and especially namespace nodes separate from and before containing elements. By comparison, if we had a parse() function, it seems it would be still easy to achieve all the same use cases, but then the actual nodes would all be created at once and have a context relative to one another. Moreover, parse() has other uses that element() and attribute() just don't solve. Cheers, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria E-Mail: boyerj@ca.ibm.com<mailto:boyerj@ca.ibm.com> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com<mailto:Nick.Van.den.Bleeken@inventivegroup.com>> To: John Boyer/CanWest/IBM@IBMCA Cc: "<public-forms@w3.org<mailto:public-forms@w3.org>>" <public-forms@w3.org<mailto:public-forms@w3.org>> Date: 11/02/2011 08:25 AM Subject: Re: Node creation functions ________________________________ John, Thank you for reading this and giving your comments. For use cases. I use those functions most when I need to set an attribute or need to insert an element of which I only have the 'template/structure' at design time because the actual values of the attributes and element text content are known at run time. Both these cases could be done in XForms 1.1 but require you to do extra set value actions after inserting the attribute/element. Being able to write the XML fragment inline makes the form much more readable in a lot of cases and makes the form less complex because you need less actions to fulfill the job (definitely when you are inserting multiple nodes at once). 1) it would be good for the examples to show the serialization of the nodes created by the example function calls I added this to the wiki 2) more text is needed to indicate what happens, if anything, in invalid scenarios, e.g. what if the qname contains an undefined namespace prefix? Will add some text for that (the undefined namespace prefix case is already covered by XPath expressions in XForms section, but I will repeat it here and also say something about invalid qnames in general) 3) More text needed to describe how the created nodes connect to the rest of the machinery of XML. For example, is the example given really intended to assign an ID to an attribute? Will subsequent calls to id() return the node? Can ID-ness be attached by adding an xsi:type attribute to an element being created? Does attribute creation include the ability to create namespace declarations? What happens when you clone a node with an insert action and update the id/xsi:type attribute? Same should happen here 4) Provide a real example where the attribute() function must be called independently of the element() function, such as inserting an attribute. I will add that example Kind regards, Nick Van den Bleeken R&D Manager Phone: +32 3 821 01 70 Office fax: +32 3 821 01 71 nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com> www.inventivedesigners.com <Mail Attachment.png><Mail Attachment.png><Mail Attachment.png> On 01 Nov 2011, at 19:58, John Boyer wrote: We have a wiki page: http://www.w3.org/MarkUp/Forms/wiki/Node_Creation_XPath_Functions This indicates the functions are "already in Orbeon". OK, why? A too-technical answer is "it would be nice to create elements/attributes not expressed beforehand in an instance", but I'm asking what are the use cases for the element() and attribute() functions? For example, one could say "I was trying to write a form that would be an XML editor and so I need to be able to create nodes whose names are defined by a user, not by a form author who wrote an instance." Question: Was this the use case, or are there any others? Going a bit further, we now have a version of spec-ready text: http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#Node_creation_Functions Feedback: 1) it would be good for the examples to show the serialization of the nodes created by the example function calls 2) more text is needed to indicate what happens, if anything, in invalid scenarios, e.g. what if the qname contains an undefined namespace prefix? 3) More text needed to describe how the created nodes connect to the rest of the machinery of XML. For example, is the example given really intended to assign an ID to an attribute? Will subsequent calls to id() return the node? Can ID-ness be attached by adding an xsi:type attribute to an element being created? Does attribute creation include the ability to create namespace declarations? 4) Provide a real example where the attribute() function must be called independently of the element() function, such as inserting an attribute. Thanks, John M. Boyer, Ph.D. Distinguished Engineer, IBM Forms and Smarter Web Applications IBM Canada Software Lab, Victoria E-Mail: boyerj@ca.ibm.com<mailto:boyerj@ca.ibm.com> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer
Attachments
- image/png attachment: image001.png
- image/png attachment: image002.png
- image/png attachment: image003.png
Received on Thursday, 3 November 2011 07:50:22 UTC