Re: Small contraditction in readonly update spec?

Hi John,

I just wanted to be sure that the group is aware of the subtle difference 
between :

  1) delete being a node change of the parent where the node is deleted 
from. 

  2) delete being a change on the node that is deleted. 

Personally I would go for option 1, because as I see deleting a node from 
its parent, only changing the parent node and not the node that is 
deleted. The deleted subtree is kept intact, like it was before it was 
deleted. Moreover I see delete as the 'opposite' action of insert I will 
find it strange that a node that is inserted can't be deleted anymore, if 
you are allowed to insert nodes, you should be able to delete them 
afterwards.

This is just my personal opinion and if the group decides to go for option 
2, I could for certain live with that. But I think it will be a bit harder 
to understand for a from designer, why he could insert nodes, but not 
delete them afterwards.

Regards,

Nick Van den Bleeken  -  Research & Development
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com

John Boyer <boyerj@ca.ibm.com> wrote on 10/05/2007 02:06:11 AM:

> 
> Hi Nick, 
> 
> Regardless of outcome, thanks for your thorough review of this topic. 
> 
> In this particular case, I believe that what I wrote is actually 
correct. 
> 
> The notion of 'replace' is like an insert followed by a *delete*, 
> and if you look at delete, you will see that it does not allow 
> deletion of a readonly node.  Clearly, if a node's parent is 
> readonly, then the node is readonly, so as you require, a readonly 
> node's content cannot be mutated by delete or submission 
> replacement.  But in the delete and submission replace cases, you 
> also cannot delete or replace a node if the node itself is readonly 
> even if the node's parent readwrite. 
> 
> For insert, it is the parent that is checked because the node itself
> does not exist until after it is inserted, so it is non-sensical to 
> check if a node "would be" readonly if it were added.  Instead, we 
> look at the parent to see if its content is mutable by insert. 
> 
> But for deletion and replacement, the node already exists and is 
> identified as readonly, so deleting or replacing it would violate 
> that model item property.  It is analogous to how relevant is 
> processed.  When a node is non-relevant, we don't just remove all 
> its attributes and content from the submission.  The relevance 
> applies to the whole node. 
> 
> 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
> 
> 
> 

> 
> Nick_Van_den_Bleeken@inventivegroup.com 
> 10/04/2007 05:58 AM 
> 
> To
> 
> John Boyer/CanWest/IBM@IBMCA, "public-forms " <public-forms@w3.org> 
> 
> cc
> 
> Subject
> 
> Small contraditction in readonly update spec?
> 
> 
> 
> 
> John,
> 
> 
> Maybe I'm reading it wrong but if I read [1] ("This operation may fail 
if 
> processing of the target attribute (including its default) yields a 
> readonly node or a non-element node.") I come to the conclusion that:
> 
> 1) when replace is 'text' submission fails if the node of which the 
> content is going to be replaced is readonly
> -> This is simular as doing a setvalue action on a node, so I think this 

> is correct
> 
> 2) when replace is 'instance' submission fails if the node that is going 

> to be replaced is readonly
> -> I think this is not desired. I think it should fail if the parent of 
> the target node that is going to be replaced is readonly. Otherwise it 
is 
> not similar to a delete followed by an insert action, what is similar to 

> doing a replace of type 'instance'.
> 
> Regards, 
> 
> Nick Van den Bleeken  -  Research & Development
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
> [1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#submit
> 
> --------------------------------------------------
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer

Received on Monday, 8 October 2007 08:44:10 UTC