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

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/