RE: repeats

When you say "all this complexion in design", would you mind giving an 
example or being more specific.

I can only assume that you are continuing the thread from Jason and 
therefore "all this complexion"
refers to the fact the question about using insert using a prototype from 
initial instance data versus 
using a prototype derived from the live running instance.

Also, your mail seems to suggest that this is complicated for you as an 
implementer.

This is where your message gets confusing to me.  This is because it is 
signficantly *easier* for the 
implementer to obtain the insert node by simply obtaining the last node of 
its nodeset or, 1.1, from 
the node returned by the origin expression. 

The original idea of taking an initial instance prototype proved 
challenging to implement.  For 
example, if your insert nodeset results in empty nodeset, you have no 
nodes, right? Which means
you have no starting point to figure out how to get from a nodeset in live 
data to a node in the
prototypical data.  It gets more fun when you try to figure out the 
prototypical node to use when
you're dealing with an inner repeat on the K^th row of an outer repeat. 

And then people started sending prepopulation data,e.g. here's where you 
left your shopping cart.
When that happened, new shopping cart items were initialized based on the 
last item in the cart
because that was the initial data referenced by the src or put in place by 
the jsp or what have you.

So, it worked for toy forms, but not for generalized web applications.  We 
fixed in in 1.0 to reflect
A) what implementers were doing anyway, and B) in favor of at least being 
*able* to create
correct applications.  We fixed it further in 1.1 to make it easier for 
the form author to express
the correct applications.

But our focus is on designing the language so that the features don't 
break when they are used
in any but the most rigid and contained scenarios.

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Francisco Monteiro" <monterro2004@tiscali.co.uk> 
Sent by: www-forms-request@w3.org
11/03/2006 08:32 AM

To
<jeacott@hardlight.com.au>, "'www-forms'" <www-forms@w3.org>
cc

Subject
RE: repeats






 
As an author of a XForms implementation I am getting more confused every
day, all this complexion in design which should be simple brings me to a
comparison of XLink and we all know where XLink is used in anger (XBRL
)which is even more complicated than what it should really be!

Perhaps it's time to pack up

Kind Regards
Francisco
 
facileXForms - Really AJAX at heart

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Jason
Sent: 03 November 2006 12:37
To: www-forms
Subject: Re: repeats 


ok - so with the new draft and xforms 1.0 I now have to load an instance 
and
a matching prototype instead of the original idea of using the initial
instance as the prototype.

in every practical xform I have made I have always ended up setting my
instance as an empty prototype anyway, then I either remove all the
offending elements in the xforms-ready event handler, or load new data 
from
somewhere.
why is the 1.1 notion any better than this? and if there is a froced
prototype (and there is) then why not label it as such, then you could
re-automate activity like the original insert idea without the xform 
author
needing to specify the default behaviour?

I was hoping that xforms was moving more toward a more free idea with
respect to managing the xml model, with the bind  elements representing 
the
effective interface between model and view. more and more I find myself
required to use xpath instead of bind in many view attributes just because
they dont accept a bind or because I cant include the xpath 
functions to get things working in combination with binds.    I was 
hoping to be able to effectively traverse unknown xml structures and 
create
trees dynamically etc. unfortunately this seems not to be the current
direction.

where would be the harm in restoring the older notion of the original
instance data operating as the default prototype? the new context and 
origin
options would not be effected and could be left in place for those that
choose to use them when they are actually needed

Jason.