XForms 1.1 - repeat relevance & editorial tweaks.

View: New views
10 Messages — Rating Filter:   Alert me  

Parent Message unknown XForms 1.1 - repeat relevance & editorial tweaks.

by Vlad Trakhtenberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Dear WG,


Is there a compelling reason for the provision that xforms-disabled/enabled event cannot target repeat (4.4.1 -4.4.11) and repeat control cannot be relevant or non-relevant (8.1.1)?

Perhaps a repeat can become non-relevant'(relevant)  and the  xforms-disabled (enabled ) fire when it does not have any (has at least one) relevant repeat items (item)?

And a couple of minor issues:

1. Typo in 8.1.1: Second bullet:
...
Note:
Form controls that read or write simpleContent produce this exception whenever and as soon as they are bound to an element node that an element child node.

2. The very first link: (not terribly useful ;) http://www.w3.org/TR/2009/CR-xforms11-20090311/  does not work.

Regards,
Vlad Trakhtenberg.

XForms 1.1 spec - typo

by Vlad Trakhtenberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Second sentence in fifth paragraph of section 1.5.6

As well, this action now als[o] performs deferred updates before its regular processing to ensure the user interface is up to date.

Thanks,
Vlad Trakhtenberg.
IBM Victoria Lab.  

XForms 1.1 - target of the xforms-delete event

by Vlad Trakhtenberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Dear WG,

According to the current XForms 1.1 spec the delete action can delete nodes from more than one XForms instance (if no delete location specified - as in 10.4 step 4 ). If so, which instance the corresponding xforms-delete event must target?

Regards,

Vlad Trakhtenberg,
IBM, Victoria Lab.

Re: XForms 1.1 - target of the xforms-delete event

by Erik Bruchez :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Good point. I guess you have something like this in mind:

<xforms:delete nodeset="instance('foo')/foo | instance('bar')/bar"/>

I think that the right fix is to dispatch xforms-delete to all the  
instances from which nodes are removed. Context information must be  
adjusted appropriately for each event dispatch.

-Erik

On May 27, 2009, at 7:54 AM, Vlad Trakhtenberg wrote:

>
> Dear WG,
>
> According to the current XForms 1.1 spec the delete action can  
> delete nodes from more than one XForms instance (if no delete  
> location specified - as in 10.4 step 4 ). If so, which instance the  
> corresponding xforms-delete event must target?
>
> Regards,
>
> Vlad Trakhtenberg,
> IBM, Victoria Lab.

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



Re: XForms 1.1 - target of the xforms-delete event

by John Boyer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Another possible fix is to have xforms delete ignore nodes which are not in the same instances as the first node, or to no-op entirely.

Insert can only insert nodes into one instance, so it is reasonable to have consistency with delete.   When delete was changed from one node to many nodes, the most urgent requirement we had in mind to satisfy was deletion of a set of children of a given node.  This can reasonably expand to nodes having a common ancestor, but crossing DOMs just seems a little much, esp. without the analogous insert ability.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <ebruchez@...>
To: Forms WG <public-forms@...>
Cc: xforms <www-forms@...>, www-forms-editor@...
Date: 05/27/2009 10:47 AM
Subject: Re: XForms 1.1 - target of the xforms-delete event





Good point. I guess you have something like this in mind:

<xforms:delete nodeset="instance('foo')/foo | instance('bar')/bar"/>

I think that the right fix is to dispatch xforms-delete to all the  
instances from which nodes are removed. Context information must be  
adjusted appropriately for each event dispatch.

-Erik

On May 27, 2009, at 7:54 AM, Vlad Trakhtenberg wrote:

>
> Dear WG,
>
> According to the current XForms 1.1 spec the delete action can  
> delete nodes from more than one XForms instance (if no delete  
> location specified - as in 10.4 step 4 ). If so, which instance the  
> corresponding xforms-delete event must target?
>
> Regards,
>
> Vlad Trakhtenberg,
> IBM, Victoria Lab.

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





Re: XForms 1.1 - target of the xforms-delete event

by Erik Bruchez :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> Another possible fix is to have xforms delete ignore nodes which are  
> not in the same instances as the first node, or to no-op entirely.

This would make the xforms-delete event much less useful.

> Insert can only insert nodes into one instance, so it is reasonable  
> to have consistency with delete.   When delete was changed from one  
> node to many nodes, the most urgent requirement we had in mind to  
> satisfy was deletion of a set of children of a given node.  This can  
> reasonably expand to nodes having a common ancestor, but crossing  
> DOMs just seems a little much, esp. without the analogous insert  
> ability.

I don't buy the consistency argument here.

We have to look at events from the perspective of form authors, not  
XForms implementors.

If xforms-delete is an event you can listen to to figure out that  
nodes were inserted into a given instance, then it needs to be  
dispatched to an instance when nodes are removed from it. If  
xforms:delete is able to delete events from more than one instance,  
then it follows that xforms-delete must be dispatched to all instances  
from which nodes were removed.

If we can't rely on an event to be accurately dispatched, then we  
should think about removing that event altogether.

-Erik

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



Re: XForms 1.1 - target of the xforms-delete event

by John Boyer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hi Erik,

I think there's a misunderstanding.  I wasn't saying that the delete *event* would not occur, but rather that the delete *action* itself should no-op if you try to delete nodes from multiple instances.

I quite agree that the delete event would be useless if you couldn't count on it to let you know whenever nodes are deleted by an XForms supported mechanism (unfortunately, you're on your own with the DOM API).

But I think form authors don't lose very much in practice if a delete action just simply doesn't work if you do a multiple instance delete.  If you want to delete from multiple instances, just write multiple deletes.  Multiple instance deletes are uncommon, and there is no effective change of the number of achievable applications by this limitation since the number of instances is static.

Also, my consistency argument is about the actions, not the events.  The XForms insert action can only insert into one instance, so it is reasonable to have an XForms delete action that can only delete from one instance.  The events are just there to target the instance that was mutated by the action.

This is the best limitation at this stage of XForms 1.1 since our only test on the xforms-delete event tests a deletion from a single instance.  There is no test coverage for multiple instance deletion, so if we modify the spec to say it is possible, then we need a test and two conforming implementations.  Given the above claim that there is no loss of power and no significant inconvenience in practice, it does not seem worth the trouble.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Erik Bruchez <ebruchez@...>
To: Forms WG <public-forms@...>
Cc: xforms <www-forms@...>, www-forms-editor@...
Date: 05/27/2009 11:02 AM
Subject: Re: XForms 1.1 - target of the xforms-delete event





> Another possible fix is to have xforms delete ignore nodes which are  
> not in the same instances as the first node, or to no-op entirely.

This would make the xforms-delete event much less useful.

> Insert can only insert nodes into one instance, so it is reasonable  
> to have consistency with delete.   When delete was changed from one  
> node to many nodes, the most urgent requirement we had in mind to  
> satisfy was deletion of a set of children of a given node.  This can  
> reasonably expand to nodes having a common ancestor, but crossing  
> DOMs just seems a little much, esp. without the analogous insert  
> ability.

I don't buy the consistency argument here.

We have to look at events from the perspective of form authors, not  
XForms implementors.

If xforms-delete is an event you can listen to to figure out that  
nodes were inserted into a given instance, then it needs to be  
dispatched to an instance when nodes are removed from it. If  
xforms:delete is able to delete events from more than one instance,  
then it follows that xforms-delete must be dispatched to all instances  
from which nodes were removed.

If we can't rely on an event to be accurately dispatched, then we  
should think about removing that event altogether.

-Erik

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





Re: XForms 1.1 - target of the xforms-delete event

by Erik Bruchez :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

John,

Got it.

This said, it would be disturbing to me that xforms:delete could  
actually support deleting nodes from multiple instances simply because  
XPath allows it, but that we would artificially prevent this from  
working.

Either way, you would have to modify the spec to reflect either 1) the  
NOP behavior or 2) the event dispatch.

Right now we say in "10.4 The delete Element":

   "The delete action is successfully completed by dispatching the  
xforms-delete event with appropriate context information."

It seems to me that it would be as easy to simply say:

   "The delete action is successfully completed by dispatching the  
xforms-delete event with appropriate context information to any  
instance from which nodes were deleted."

And from the implementor's perspective, it doesn't make a big  
difference either. The win is increased consistency.

-Erik

On Jun 2, 2009, at 11:31 AM, John Boyer wrote:

>
> Hi Erik,
>
> I think there's a misunderstanding.  I wasn't saying that the delete  
> *event* would not occur, but rather that the delete *action* itself  
> should no-op if you try to delete nodes from multiple instances.
>
> I quite agree that the delete event would be useless if you couldn't  
> count on it to let you know whenever nodes are deleted by an XForms  
> supported mechanism (unfortunately, you're on your own with the DOM  
> API).
>
> But I think form authors don't lose very much in practice if a  
> delete action just simply doesn't work if you do a multiple instance  
> delete.  If you want to delete from multiple instances, just write  
> multiple deletes.  Multiple instance deletes are uncommon, and there  
> is no effective change of the number of achievable applications by  
> this limitation since the number of instances is static.
>
> Also, my consistency argument is about the actions, not the events.  
> The XForms insert action can only insert into one instance, so it is  
> reasonable to have an XForms delete action that can only delete from  
> one instance.  The events are just there to target the instance that  
> was mutated by the action.
>
> This is the best limitation at this stage of XForms 1.1 since our  
> only test on the xforms-delete event tests a deletion from a single  
> instance.  There is no test coverage for multiple instance deletion,  
> so if we modify the spec to say it is possible, then we need a test  
> and two conforming implementations.  Given the above claim that  
> there is no loss of power and no significant inconvenience in  
> practice, it does not seem worth the trouble.
>
> Cheers,
> John M. Boyer, Ph.D.
> STSM, Interactive Documents and Web 2.0 Applications
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@...
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>
>
>
> From:
> Erik Bruchez <ebruchez@...>
> To:
> Forms WG <public-forms@...>
> Cc:
> xforms <www-forms@...>, www-forms-editor@...
> Date:
> 05/27/2009 11:02 AM
> Subject:
> Re: XForms 1.1 - target of the xforms-delete event
>
>
>
>
> > Another possible fix is to have xforms delete ignore nodes which are
> > not in the same instances as the first node, or to no-op entirely.
>
> This would make the xforms-delete event much less useful.
>
> > Insert can only insert nodes into one instance, so it is reasonable
> > to have consistency with delete.   When delete was changed from one
> > node to many nodes, the most urgent requirement we had in mind to
> > satisfy was deletion of a set of children of a given node.  This can
> > reasonably expand to nodes having a common ancestor, but crossing
> > DOMs just seems a little much, esp. without the analogous insert
> > ability.
>
> I don't buy the consistency argument here.
>
> We have to look at events from the perspective of form authors, not
> XForms implementors.
>
> If xforms-delete is an event you can listen to to figure out that
> nodes were inserted into a given instance, then it needs to be
> dispatched to an instance when nodes are removed from it. If
> xforms:delete is able to delete events from more than one instance,
> then it follows that xforms-delete must be dispatched to all instances
> from which nodes were removed.
>
> If we can't rely on an event to be accurately dispatched, then we
> should think about removing that event altogether.
>
> -Erik
>
> --
> 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/



Parent Message unknown Re: XForms 1.1 - target of the xforms-delete event

by John Boyer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hi Vlad,

The working group decided that the behavior of delete action when the nodeset obtains nodes from multiple instances is undefined by the specification, leaving it open in XForms 1.1 for implementers to handle the case as they see fit.

Can you please let us know if this is acceptable to you for XForms 1.1?

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw




From: Vlad Trakhtenberg/CanWest/IBM
To: public-forms@..., www-forms@..., www-forms-editor@...
Cc: John Boyer/CanWest/IBM@IBMCA
Date: 05/27/2009 07:53 AM
Subject: XForms 1.1 - target of the xforms-delete event




Dear WG,

According to the current XForms 1.1 spec the delete action can delete nodes from more than one XForms instance (if no delete location specified - as in 10.4 step 4 ). If so, which instance the corresponding xforms-delete event must target?

Regards,

Vlad Trakhtenberg,
IBM, Victoria Lab.


Re: XForms 1.1 - target of the xforms-delete event

by Vlad Trakhtenberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Thanks for your reply. Sounds fine to me. Vlad Trakhtenberg.



John Boyer/CanWest/IBM@IBMCA
Sent by: www-forms-editor-request@...

11/06/2009 08:11

To
Vlad Trakhtenberg/CanWest/IBM@IBMCA
cc
public-forms@..., www-forms@..., www-forms-editor@...
Subject
Re: XForms 1.1 - target of the xforms-delete event






Hi Vlad,


The working group decided that the behavior of delete action when the nodeset obtains nodes from multiple instances is undefined by the specification, leaving it open in XForms 1.1 for implementers to handle the case as they see fit.


Can you please let us know if this is acceptable to you for XForms 1.1?


Thanks,

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@...  

Blog:
http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw



From: Vlad Trakhtenberg/CanWest/IBM
To: public-forms@..., www-forms@..., www-forms-editor@...
Cc: John Boyer/CanWest/IBM@IBMCA
Date: 05/27/2009 07:53 AM
Subject: XForms 1.1 - target of the xforms-delete event





Dear WG,


According to the current XForms 1.1 spec the delete action can delete nodes from more than one XForms instance (if no
delete location specified - as in 10.4 step 4 ). If so, which instance the corresponding xforms-delete event must target?

Regards,


Vlad Trakhtenberg,

IBM, Victoria Lab.