Re: Node creation functions

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

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>
To:     John Boyer/CanWest/IBM@IBMCA
Cc:     "<public-forms@w3.org>" <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
www.inventivedesigners.com




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 

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
> 
To:        John Boyer/CanWest/IBM@IBMCA 
Cc:        "<public-forms@w3.org>" <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
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 

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, 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, and is 
believed to be clean. 



Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer