Re: repeats

Jason wrote:

 > and since it is still ONLY in draft form I'd like to see v1.0
 > amended to be useful again.

Again I understand your issue with the current status of insertions
with 1.0 Second edition, but there is very little chance that the
working group will be convinced to revert the behavior, because we are
talking about going from one sub-optimal solution to another
sub-optimal solution and back. Better concentrate on XForms 1.1 which
provides something better than both old solutions (at least from the
working group's perspective, and I agree with that), and better for
you to kick your vendor so that they implement XForms 1.1, or at least
parts of it ;-)

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>

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>

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

With 1.1 you work with an insertion template:

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

You insert a new employee as follows:

<xforms:insert context="instance('employees')" nodeset="employee"
                origin="instance('employee-template')"/>

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.

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>

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

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

 > I'm surprised that everyone hasn't implemented the 1.1 insert
 > attributes given the mess that the 1.0 version leaves us with, but
 > then again it is only draft.

Well, most active implementors I think are implementing the parts of
the draft that they find useful and think will remain stable, and this
is good for everybody because there is no better way to find issues
with a spec than starting to implement it.

 > On the new prototypical data requirements, isnt it kind of weird that an
 > xform instance can have a schema, and a prototypical instance? why not
 > just enforce a schema definition for an xform's data?, wouldn't that
 > achieve the same thing as prototypical data but with capacity to also
 > specify datatype/node ranges etc? and again delete the requirement to
 > specify an origin for most inserts?

First, not everybody wants to use a schema with XForms.

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.

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

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Tuesday, 7 November 2006 10:54:07 UTC