Re: repeats

Hi Jason,

Sorry, but the stuff you are writing is really hard to respond to.  It's 
just a stream of thoughts that makes huge assumptions every few sentences 
that I understand certain things you haven't said.

For example, you say that great care would needed to be taken when dealing 
with newly loaded data sets that might be subtly different than prior ones 
in the form.  It escapes me how this point manages to substantiate the 
complaint about the processor not taking a snapshot of instance data on 
initialization.  In fact, you are exactly describing one of the things 
that was broken about the old method. 

In XForms 1.0, the <instance> element contains or references the initial 
instance data, and the snapshot was taken during model-construct.  If an 
instance replacement submission brought in new data over which a 
repeat/insert should operate, but there was no matching data in the 
initial instance data, then insert would just fail. 

So yes, when one is writing an application, one must be cognizant of the 
schema that will be processed during the run of the form.  If you want to 
add nodes, you have to know what the initial form looks like, and you have 
to drag that into your form.  But with the current design, you can even do 
that dynamically.

This conversation would therefore really benefit from some exact use cases 
with example markup because your claim that XForms repeats are now just 
for toy forms is not just hyperbole, it's just plain wrong.  The new 
design even of XForms 1.0 allows one to actually create arbitrarily deeply 
nested repeats, not just one level, and it allows one to do so in a way 
that survives a save/reload (e.g. submit data to server and come back 
tomorrow to finish purchase order).

And I still don't understand why you believe that insert on empty nodeset 
should do something.  Even if you did have a prototype available (i.e. 
pretend the above language faults did not exist), when the nodeset 
resolves to empty, where should the node be inserted?

Language design is hard because all the features have to work together all 
the time.  Things should be as simple as possible *but no simpler*.  You 
can't introduce a feature of the language that is "elegant" by itself, but 
breaks down as soon as you try to use it in a more sophisticated way with 
other language constructs.  To some extent, you argue this very point when 
say that you should be able to drive a switch with instance data.  My 
response would be that you should be able to use a submission to load data 
that had no representation in the initial instance data and expect that 
repeat and insert will not cease to function as specified.  By comparison 
to that flaw, your point about switch is far lower in priority because 
it's not a case of a specified feature not working in certain cases.  It's 
just that you want a more sophisticated feature.  And, finally, note that 
I am only using your switch comment as an example for comparison. 
Regarding that particular feature, you are preaching to the converted.

This letter could be a lot longer trying to address all the stuff you're 
talking about, but we need to start having shorter, more focused dialog 
because these just take too long to do.  I'll start by cutting it here :-)

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





Jason <jeacott@hardlight.com.au> 
11/03/2006 04:43 PM
Please respond to
jeacott@hardlight.com.au


To
John Boyer/CanWest/IBM@IBMCA, www-forms <www-forms@w3.org>
cc

Subject
Re: repeats






ok - having calmed down I realise that all is not lost in the long term, 
  I am just stuck until chiba implements the 1.1 insert features, or my 
clients are ready to use a clientside implementation (they are 
definitely not!)
to be fair, when I was first learning to use xforms I couldnt understand 
why there wasnt a prototype (or a way to set up a pseudo one) as it 
would have made the xforms-ready hack redundant for initially clearing 
nodes, and made everything a bit clearer. I certainly like that the 
option now exists but resent being forced to use it. But having now got 
used to the idea that I need to set my initial instance data to act as 
an effective prototype I can see that both options can work together 
without any conflict and without forcing a given form to carry a 
suitable prototype to match any loaded data. I havent really thought 
about it yet but I think at least this may lead to problems where a 
loaded prototype doesnt match loaded data for a given view so great care 
would need to be taken when updating/loading new data, especially if the 
same form is intended to handle subtly different datasets.

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

I know this was not directed at me but I'd like to add something. I 
think Xforms probably is more complex than it needs to be and more 
restrictive than it should be, but generally I have liked the track its 
taken.
Complexity comes particularly for me because I often cant do things I 
expect i could - like to simply use toggle based on instance data eg: 
<xf:toggle id="toggle-something" xf:case="bind or xpath expression" 
defaultcase="someknowncase" /> - or to be able to dynamically set a bind 
  in a view control(that would enable proper treewalking i think).
This must be the case for most people because there are lots of 
"techniques" that get listed in order to workaround problems and acheive 
basic goals and many of them are quite cryptic.
I must admit that I find it difficult to really fault 1.1 because I am 
just not very familiar with actually using it (I do think that the 
'insert for the zero case does nothing' should be amended though).
These are not necessarily "complexity in design" issues, but are some 
thoughts on what makes forms complex to create and to maintain.
Generally I find it very difficult to reuse code with xforms - every 
time I choose to use a switch I end up reproducing some code for each 
case. It would be nice if there was a way to include/call sub functions 
without needing to resort to generating/trapping events which gets 
really complicated fast. You always need to be aware of everything at 
once when you start playing with events so I have avoided using them as 
much as possible.
I truly cringe everytime I have to enter an xpath inside the 'at' clause 
of an insert etc - why cant I select an existing bind reference? after 
all I already typed that path once. perhaps I'm looking at binds all 
wrong, but I thought they were intended to help isolate the model from 
the view so that the same view could be used with different models and 
schemas as long as the binds were compatible. I also thought binds were 
there to act as prototypes in the case where no data exists at all. at 
the very least I ought to be able to leverage the inherent xpath 
represented by a bind everywhere possible. This complicates things 
because the xpath varies depending on the current context, but a bind is 
a bind - so changes to instance structure typically for me require 
changes throughout the view as well.
I recently saw a form generated via the ibm form builder tool thingo - 
it was a single form a mile long for tax calculation. I dont know how it 
could be reasonably maintained or worked on by multiple people, and 
looking at the actual code - well u just dont want to think about it.

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

These both seem much the same to me. I thought from an implementors 
perspective that for the case of "using a prototype from initial 
instance data" you'd just copy the initial instance data into memory 
somewhere so you always have a reference -so you are basically in the 
same position as 1.1 - if the fine folks at chiba could manage it then 
why not everyone else? It took the XSLT implementors ages to get fully 
working processors but I never noticed reasonable spec features alter to 
suit implementors.

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

sure - but far from impossible. I agree that it would be nearly 
impossible if Xforms allowed the freedom it should to create and manage 
arbitrary XML in the model, but it doesn't. there is no scope for 
generating random child elements and attributes at runtime, so tracking 
the original nodeset and the actual instance ought not be too difficult, 
and if it turns out that a parent node (or perhaps better, no 
identifiable ancestor) is missing then in that case fine -do nothing on 
an insert because that makes sense, but to change the spec to read 
'insert does nothing when all the nodes are gone' is totally 
counterproductive and really does add complexity.

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

ok - but if people are dynamically creating xforms (even changing 
instance data via jsp etc is actually rewriting your form!) then they 
need to expect that because in effect they are creating forms with 
errors - but if you are using an xform in a way that it was presumably 
intended then your initial form remains constant - prototype in place - 
and any data loaded by the form itself doesn't cause any grief at all.

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

I'm afraid I have to disagree. I really do consider Xforms 1.0 totally 
broken in this respect since it is nigh on impossible to use the 
insert/delete/repeat cycle for anything practical. It is now ONLY useful 
for toy forms and forms that dont attempt to add/remove data. I'd argue 
that "correct" but useless applications ought not be a strong focus. 
Probably the primary reason I choose to use xforms over anything else is 
to be able to easily manage forms that represent datasets that change 
size. 1.1 makes it again possible to build practical forms, although 
necessarily slightly longer forms.

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

I had thought your focus would be on creating an elegant forms platform 
first, and then if something does turn out to be impossible or 
impractical to implement then it should be addressed?

I do think to a large extent you have very much succeeded in creating a 
useful platform with xforms, please dont give up the search.

Cheers
Jason.