W3C home > Mailing lists > Public > public-forms@w3.org > November 2011

Re: Node creation functions

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Thu, 3 Nov 2011 15:39:18 +0000
To: John Boyer <boyerj@ca.ibm.com>
CC: "<public-forms@w3.org>" <public-forms@w3.org>
Message-ID: <3E73B1DD-2B71-40DE-8228-5C323A3CD328@inventivegroup.com>
John,

You are correct I did want to refer the the evaluation context without evaluating the context attribute… and not '.' but you are correct that this is currently a problem...

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 03 Nov 2011, at 14:49, John Boyer wrote:

Hi Nick,

As an aside, I didn't quite understand why you were using the context() function in the origin attr.  I think it would return the *result* of the context attribute.  But this is also what "." would return.  One of my other emails is about fixing insert so that we can refer to a "parent" node without changing the context at the same time.  Is that issue applicable to your examples, or could context() be replaced with "." in your examples below?

I think the parse examples would have less entity encoding, and be more readable, if they actually did express "content that is entered by a person who is filling the form".  The &lt; would still be there, but it would be a lot more readable.

The "bizarreness" is just that the element() and attribute() functions are evaluated in a way that creates the final resultant DOM in a bottom-up fashion, so you get attributes that are created first before their owning elements, even though an orphaned attribute would not be syntactically recognized by XML until some later point when it is attached into a DOM.  It's not that it doesn't work, it just feels a bit hacky.  I just wanted to end up with an example where it was clear that this is what was really needed.  A good example to have in attribute() would be an actual insert action that inserts an attribute with a value.  This will also help drive real test case forms.

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





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/03/2011 12:50 AM
Subject:        Re: Node creation functions
________________________________



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('&lt;value id=&qout;my-value&quot;&gt;John&lt;/value&gt')"/>


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('&lt;value id=&qout;', xf:escape-xml(xf:context()/id),'&quot;&gt;', xf:escape-xml(xf:context()/name),'&lt;/value&gt'))"/>

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


<Mail Attachment.png><Mail Attachment.png><Mail Attachment.png>

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

--
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



image001.png
(image/png attachment: image001.png)

image002.png
(image/png attachment: image002.png)

image003.png
(image/png attachment: image003.png)

Received on Thursday, 3 November 2011 15:39:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:56 UTC