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.