Re: 15 Insert/Delete Examples updated in Editor's draft

Hi Erik,

Notwithstanding whether the intent of your proposal was misunderstood, the 
thing you proposed (the removal of certain text) did occur.

Can you reformulate what you want to happen based on the latest copy of 
the spec?
This will be needed for comparison.

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

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
11/04/2007 11:27 AM
Please respond to
ebruchez@orbeon.com


To
"Forms WG (new)" <public-forms@w3.org>
cc

Subject
Re: 15 Insert/Delete Examples updated in Editor's draft







John & all,

Currently, if you specify a node using @nodeset, an insertion can take
place:

1. Before or after that node

or:

2. Within that node

The whole purpose of my change was to remove this "or". I believe that:

1. It makes insert appear more complicated than it really is. It is
    not trouble, it is a *simplification* of the current text.

2. We don't need it since we have the @context attribute to perform
    insertions within a node.

Here is the scenario that I am trying to fix:

   <xforms:insert nodeset="employee" origin="instance('contractor')"/>

What this does: my contractor element is inserted *before* or after
the existng employee element.

Now this:

   <xforms:insert nodeset="employee" 
origin="instance('contractor')/@attribute"/>

The attribute is inserted *as a "child"* of the contractor element.

This does not make sense to me. Why do we want two different behaviors
when we deal with different types of nodes? I want it to be clear when
we do an "insert before or after" and an "insert within" operation. My
proposal took care of this.

I really don't like the approach whereby we insert "here" if possible,
"there" if that failed. No, the form author specifies where the
insertion takes place, and we must honor that request. I don't see a
benefit in not doing so.

@nodeset never worked as an insertion container in 1.0. I don't think
we need it to work as one in 1.1 since we have the @context attribute.

So my proposal came down to using the @context attribute to specify a
container for insertion. This is not something new, right, this is
what we do when we write:

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

or if a @nodeset attribute returns an empty node-set. Either way,
@context is the container for the insertion.

The same can be used perfectly nicely to insert an attribute into an
element:

   <xforms:insert context="employee" 
origin="instance('employee')/@attribute"/>

In that case, we don't use a @nodeset attribute, simply because there
is no need for it. You can use the @nodeset attribute if you want:

   <xforms:insert context="employee" nodeset="@*"
                  origin="instance('employee')/@attribute"/>

(Although I strongly dislike this as it insists that you can control
attribute order, and I was not in favor of allowing this.)

Now remains my other releated issue:

 >    For example, you may want to insert a text node or even a
 >    processing instruction node before or after an element. This is
 >    not possible because of the text in 2b [...]"

If I write:

   <xforms:insert contex="employees" nodeset="employee"
                  origin="instance('employee')/text()"/>

What will happen to my text node? Will it be inserted before or after,
or within the employee element? How will I, as a form author, know for
sure without torturing my brain?

With my proposal, it is clear: the insertion will always take place as
a child of the employees element, not as a child of the employee
element.

In summary, with my proposal, we never have to make a desision on the
insertion point based on the type of the cloned nodes: either the node
can be inserted at the location intended by the author, or it cannot
and then we NOP, the later being an accepted behavior. It is a
simpler, more consistent proposal, it addresse all the use cases we
have with no drawback in my opinion. I do not see in your comments
below anything that really goes against it.

-Erik

John Boyer wrote:
 >
 > Hi Erik,
 >
 > The text you submitted was sent after the publication request had
 > already been made for the last call working draft.
 >
 > We did however, treat your comment sent Feb. 16 as a last call comment,
 > and we removed Part 6b.  Things have changed a little after last call,
 > but if you go into the diff marked spec, you will see the point was
 > removed, though it is called 7e.
 >
 > It was not clear in your last call comment that your real intent in
 > removing that text was to place a limitation on nodeset that it could
 > only be used to specify a node to insert before or after.
 >
 > This is impossible to assert in the case of a nodeset that identifies 
an
 > attribute since attribute order is not assured.  Thus, in order to
 > address another last call comment that appeared numerous times, we 
place
 > the step 7a at the front of identifying the target location of the
 > insertion.  It says that if the cloned node is an attribute, then the
 > target is an attribute list of either the insert location node if an
 > element or its parent otherwise.  This is overall the best behavior for
 > inserting an attribute because it places the attribute in the nearest
 > sensible location relative to the insert location node.
 >
 > I think your request amounts to a request to remove 7a, but also to
 > change 7c to decide between the child list and the attribute list based
 > on the type of cloned node... and to add some other kind of step to say
 > that if the Nodeset identifies an attribute, then the target location 
is
 > the attribute list.
 >
 > I don't see the point of going to all this trouble to achieve the 
effect
 > of making insert fail when a person says 'I know the node I want to
 > insert an attribute into, so I write
 >
 > insert nodset="that node" origin="some attribute"
 >
 > Granted they could also use
 >
 > insert context="that node" origin="some attribute"
 >
 > but we added context as something you use when you need to specify a
 > parent element because the nodeset might fail.  The mental model for
 > nodeset coming out of XForms 1.0 is that you use it because know of an
 > exact node or set of nodes.  With your change, there would be a case
 > where I have an exact node that I want to add an attribute to, but the
 > use of nodeset would unexpectedly fail on me.
 >
 > In conclusion, the example in the current editor's draft works, and it
 > does so because step 7a provides both a simplified implementation 
scheme
 > for dealing with attributes and a very reasonable viewpoint for form
 > authors regarding the use of nodeset in insert.  I think we should 
leave
 > it alone at this point.
 >
 > John M. Boyer, Ph.D.
 > STSM: Lotus Forms Architect and Researcher
 > Chair, W3C Forms Working Group
 > Workplace, Portal and Collaboration Software
 > IBM Victoria Software Lab
 > E-Mail: boyerj@ca.ibm.com
 >
 > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >
 >
 >
 >
 > *Erik Bruchez <ebruchez@orbeon.com>*
 > Sent by: public-forms-request@w3.org
 >
 > 10/12/2007 01:06 PM
 > Please respond to
 > ebruchez@orbeon.com
 >
 >
 > 
 > To
 >               "Forms WG (new)" <public-forms@w3.org>
 > cc
 > 
 > Subject
 >               Re: 15 Insert/Delete Examples updated in Editor's draft
 >
 >
 > 
 >
 >
 >
 >
 >
 >
 > John & all,
 >
 > There is one example which doesn't work as I expect: B.4 Set
 > Attribute. I also don't understand the note "The context attribute is
 > not used because this pattern assumes the ability to indicate an exact
 > element to receive an attribute list, so nodeset is used."
 >
 > I proposed a change to the text for insert was changed a while ago,
 > for consistency and simplicity reasons, as follows: when specifying a
 > nodeset, you always insert before or after a node in the
 > nodeset. Period. As simple as that. If a particular insertion doesn't
 > make sense, then we NOP (e.g. inserting an attribute before an
 > element).
 >
 > However, it seems that this change did not make it to the to current
 > version of the spec, and I wonder why as I though that this change had
 > been agreed upon. Here is the reference, and I even wrote the spec
 > ready text for it, see:
 >
 >   http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0111.html
 >   http://lists.w3.org/Archives/Public/public-forms/2007Jul/0069.html
 >
 > Read in particular the following rationale:
 >
 >   "In the new text for 1.1, point 6b makes a distinction between two
 >    cases: either the cloned node is of the same type of the insert
 >    location node, or it is different. If it is of the same type, then
 >    the new node is inserted before or after, but if the type is
 >    different the node is inserted as a *child* of the insert location
 >    node.
 >
 >    This sounds to me like an inconsistent behavior, and my guess is
 >    that this is informed by XForms 1.0's homogeneous collection
 >    heritage. But it also prevents certain use cases. For example, you
 >    may want to insert a text node or even a processing instruction
 >    node before or after an element. This is not possible because of
 >    the text in 2b [...]"
 >
 > So now again, it seems we still this situation whereby the point of
 > insertion depends on the type of the cloned node, which makes spec,
 > implementation and writing more complex.
 >
 > So IMO the right way of writing this example is:
 >
 >   <xforms:insert context="item[2]" origin="item[1]/@rating"/>
 >   <xforms:insert context="item[3]" origin="item[1]/@rating"/>
 >
 > The meaning of this is that you insert the attribute as a child of the
 > element.
 >
 > -Erik
 >
 > John Boyer wrote:
 >  >
 >  > The XForms 1.1 draft available from our home page now contains 15
 >  > example patterns for insert and delete actions.
 >  >
 >  > Please review
 >  >
 > 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#insert-delete-patterns 


 >
 >
 >  >
 >  >
 >  > Thanks,
 >  > John M. Boyer, Ph.D.
 >  > STSM: Lotus Forms Architect and Researcher
 >  > Chair, W3C Forms Working Group
 >  > Workplace, Portal and Collaboration Software
 >  > IBM Victoria Software Lab
 >  > E-Mail: boyerj@ca.ibm.com
 >  >
 >  > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
 >  >
 >
 >
 > --
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
 > http://www.orbeon.com/
 >
 >


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/