RE: repeats

Hi everybody,

I will try to recap the issues arisen in my previous post about reset and
insert that were partially discussed again in the long Jason thread. What it
is included below it is written without reviewing the spec, so I could
mistake something. My apologies if this happens.

- the reset action requieres to come back to the model state after the
xforms-ready. Therefore, there seems to be a requirement for a processor to
'remember' the initial state of the model(s) already in the spec. This could
be done in different ways and does not need to be a full blown DOM tree copy
of the model(s).

- regarding the long discussed insert issue, this is my opinion. The insert
as per 1.1 works fine. Some performace issues with this solution are
explained below in relation with the reset. The solutions for 1.0 seem
artificial to me and very little declarative and very programmatic. it also
poses some problems already mentioned in the thread. The solution based on
the intial instance state seems like an improvement over the current
situation. The details related to nested repeats and prepolulated instances
should be worked out before arriving to any conclusion. BTW, DataMovil
implemented this solution since a long time ago, and takes into account
prepopulated instances although since it does not support nested repeats
this issue was not tackled.

- in relation with my proposal to include an instance attribute to the reset
element, I still do think it should be in the spec. The main reason is that
the insert solution poses memory problems: instance data tends to be large
in actual form applications (actually larger than the control part). If an
instance needs to de duplicated to reset it to the the initial state, this
cannot be achievable for resource constraint devices. Optimized recollection
of the initial state is more feasible. Another reason is that to reset the
instance is declarative while the insertion is more programmatic. The issues
around ids, and defaulting should be worked out but I do not see much of a
problem there. I do not see any specific issue in the instances
inconsistencies mentioned by someone. Since 'my' reset can be achieved by
other means, in any case, they are common to the process model in Xforms in
general.

My last point is that we, as a group, should be sensitive to resource
constraint devices issues as long as they do not jeopardize the
functionalities for the desktop. Take into account that for every desktop,
there are ten mobile devices in the world. It is up to the IT industries to
make data applications happened in that environment.

Best regards,

Rafael


  _____  

De: www-forms-request@w3.org [mailto:www-forms-request@w3.org] En nombre de
John Boyer
Enviado el: martes, 07 de noviembre de 2006 18:35
Para: jeacott@hardlight.com.au
CC: Erik Bruchez; www-forms@w3.org; www-forms-request@w3.org
Asunto: Re: repeats



Hi Jason, 

Somewhere in the depths of the mail below you make the statement "if you do
this in XForms 1.0 [first edition] you never have any trouble" 

The fallacy of this claim is why XForms 1.0 got changed. 

There are also a lot of yep's below.   
The first agrees that a database might start with zero employees and that
you'd be "stuck" with XForms 1.0 SE. 
The second agrees that  in XForms 1.0 first edition, the employees has to
start with the prototype. 

But in that regard, there is no change between first and second edition?!? 

In 1.0 second edition, the prototypical data is maintained in the running
data, which means 
you can delete it *if you want* by simply using a relevance bind, like this:


<bind nodeset="item[last()]" relevant="false()"/> 

XForms 1.0 SE gives you *the option* to do this deletion, whereas XForms 1.0
forced it 
on you.  The option is better because there is a downside to the deletion,
which is that 
if the collected data is ever returned to the client-side for further
amendment, then the 
server-side of the web application must reinsert the prototypical data as
the last node. 
And of course, this didn't work out so well for those who support file:
URIs. 

Given that the whole thing has been made more sensible by the addition in
XForms 1.1 
of the origin and context attributes, the persistence of your debate is a
little mystifying. 
To wit, you still have not indicated where you think that insert should
insert its prototype 
node when the nodeset becomes empty. 

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> 
Sent by: www-forms-request@w3.org 


11/07/2006 04:43 AM 


Please respond to
jeacott@hardlight.com.au



To
Erik Bruchez <ebruchez@orbeon.com> 

cc
www-forms@w3.org 

Subject
Re: repeats

	





thanks for this,
                I know we are both talking about the same thing and I really
do know 
that I'm flogging a dead horse here, but I will use your illustration to 
make my point once more too.

Erik Bruchez wrote:
> I just wanted to make the 1.1 way clearer below (but I think it's
> already clear for you Jason):
> 
> Let's say my employees document, as stored in my neat XML database,
> contains 0 employee. It looks like this:
> 
> <xforms:instance id="employees">
>   <employees/>
> </xforms:instance>

yep

> 
> With 1.0 second edition, you are stuck: you don't have the prototype
> for new <employee> elements to insert at all. You have to follow
> John's way, which involves actually adding an <employee> element as
> child of <employees>. But then it adds this constraing on your
> document that you don't necessarily want to have.
> 
> With 1.0 original behavior, you need to have the prototypes like:
> 
> <xforms:instance id="employees">
>   <employees>
>     <employee>
>       <first-name/>
>       <last-name/>
>     </employee>
>   </employees
> </xforms:instance>

yep

> 
> And then, upon xforms-ready, override that instance with the document
> you load from the database.

which you are doing anyway (loading the new data I mean).

> 
> With 1.1 you work with an insertion template:
> 
> <xforms:instance id="employee-template">
>   <employee>
>     <first-name/>
>     <last-name/>
>   </employee>
> </xforms:instance>

yep - so we are at square 1 - exactly the same as the previous 1.0 
example. you have defined everything you need in your form - just as you 
have in 1.0 - zero difference so far.

> 
> You insert a new employee as follows:
> 
> <xforms:insert context="instance('employees')" nodeset="employee"
>                origin="instance('employee-template')"/>

yep - so now you need to know what node you are copying from - 
previously it was inherent and impossible to copy from the wrong node.

> That's very clean in my opinion. You make it very explicit what the
> template is, and how it is copied. (I like explicit.) And you don't
> have anything like an XForms instance that has an "original" state
> that is used for templates, and a "current" state.

but you can always see the initial state in your xform with 1.0 just as 
you can in your 1.1 variation. they are identical, but you have to 
manually assign the origin for 1.1

> Note that you could as well have a prototype for your whole document
> if you want:
> 
> <xforms:instance id="employees-template">
>   <employees>
>     <employee>
>       <first-name/>
>       <last-name/>
>     </employee>
>   </employees
> </xforms:instance>

now we are exactly at 1.0 - if you do this as your instance data in 1.0 
you never have any trouble and you also never have to specify origin 
nodes and potentially all those extra binds (if you choose to use them)

in 1.0 you've got
<xforms:instance id="employees-template">
  <employees>
    <employee>
       <first-name/>
       <last-name/>
    </employee>
   </employees
</xforms:instance>

plus any binds

and in 1.1 you've got

<xforms:instance id="employees">
</instance>

<xforms:instance id="employees-template">
  <employees>
    <employee>
       <first-name/>
       <last-name/>
    </employee>
   </employees>
</xforms:instance>

plus any binds to employees-template + hopefully working lazy binds to 
instance employees (or else we need to duplicate our instance 
employees-template in instance employees just to use binds for that too)

ok - so far I dont think readability is any better, and if I get a bind 
or a ref wrong in my origin I'm only going to break my form as soon as 
it does the copy and a few binds or controls dont match. So copying from 
arbitrary nodes probably wont work anyway, so we've really only added 
complexity here. Unless an instance has nothing directly interested in 
it (via binds, controls etc) then copying arbitrary stuff to it doesnt 
get you any further than insert+setvalue
I dont think its really any clearer and it will certainly make building 
xforms with all the appropriate new origin/target linkages on the fly 
more complex, and if you think about whats involved in that process then 
perhaps you come to the same conclusion as me that it could be automated 
by the processor as long as you start out with a fully representative 
instance.

> 
> <xforms:insert context="instance('employees')" nodeset="employee"
>                origin="instance('employee-template')/employee"/>
> 
> It's your choice. The key is to recognize that a typical XML document
> that deals with repeated sections may not contain templates for those
> repeated sections (here the <employee> elements), ergo you have to
> externalize those templates.

but it would contain those templates if you, as the xforms designer, 
recognised this (and you clearly do!) and included a properly 
representative initial instance, just as you are forced to do with 1.1 - 
its just the same!!!
In both cases if you dont include the proper prototype data the form 
fails. There are Identical requirements by the author to provide this 
data, only 1.1 is more verbose and more error prone for the author.
I read somewhere once that it takes an average programmer an average 1 
hour to fully debug and document every 10 lines of code, irrespective of 
the language. So I've always thought that the more you can get done in 
one line, the less time it takes to complete a project. I have no idea 
if this is true  however ;-) but it seems about right to me.

> (As a side note, xforms:insert as of 1.1 is now a generic XML copy
> action that is no longer tied to xforms:repeat as it was in XForms
> 1.0. This is mainly enabled by the new @context and @origin
> attributes.)

A very good thing - more xforms features should be allowed to be used 
more broadly.

> Also, creating an XML document from an XML Schema type is not always
> easy! By expanding a schema, you may also end up with a "maximal" XML
> document that contains all the choices, all the optional attributes,
> etc. In the worst case scenario, you have recursion.

recursion would be bad, but you could allow the xforms processor to 
default to the minimal insertion, allow it to be happy about ignoring 
binds that dont exist (say to an attribute that wasnt initially created) 
and to be happy to add them as required by form useage.
My point was only that there is now triple redundancy in data 
definition. The instance (potentially but not mandatory), the new 
prototype, plus any schema if used. I'm not wild about schema's but if 
the problem is rooted in the allowed data definition then it seems a 
viable solution.

>  > it just seems that with the new solution, people will be required to
>  > manually specify the source for every element, and 99% of the time
>  > the information is already there.

> Not in my experience, but that's just me.

your example above required a manual specification where it was entirely 
redundant with 1.0.
origin="instance('employee-template')/employee"
(if you'd used a bind that would have been redundant too)

Cheers
Jason.