Re: Added text regarding nodes that don't belong to an instance

Hi Nick,

I think the reason you have to do this is because we have no way to create 
a named association between a non-instance node and an instance node.

It would be cool and powerful to have an action or function that would 
setAssociation(name, orphanNode, instanceNode).

Then, of course we'd need a getAssociation(name, instanceNode) that would 
return the orphanNode.

At that point, the so-called orphan node is essentially a "shadow tree" 
attached to a node of the instance DOM. 

There'd be nothing wrong, then, with any node in such associated tree 
being the target of further associations.  Shadows on shadows. 

If you setAssociation() on a name that already has an association, then I 
imagine that should replace the association, which should destroy the 
replaced shadow tree (unless it is referenced someplace else, of course).

Actions like insert and deletion should be allowed on these shadow trees, 
so they can be mutated.

I also can't really think of anything really wrong with associating a 
subtree root in one live instance with a node in another live instance. By 
nothing wrong, I mean nothing about lifecycle/deletion that can't be 
worked out in a natural way.  For example, if you delete a node from an 
instance, but that same node is also associated with a node of another 
instance, then that should just be OK.  It would just be deleted from the 
live instance as requested but remain associated with the other node, so 
it would not be destroyed.

Anyway, the connection back to your email is that there'd also be nothing 
technically wrong with binding MIPs to the shadow tree nodes, whether or 
not they are a part of a live instance.  Maybe a way to look at this is 
that an associated node is *indirectly* part of an instance, and only 
nodes that are created out of the blue and not associated with an instance 
are subject to the rules you describe.

Maybe this is all just way too much fun for a form author to have, but... 
seemed worth mentioning as a possibility and drumming up some discussion 
about it.

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

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





From:   Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
To:     Public Forms <public-forms@w3.org>
Date:   06/30/2011 07:29 AM
Subject:        Added text regarding nodes that don't belong to an 
instance
Sent by:        public-forms-request@w3.org



All, 

I added the following text to '9.5 The XForms Function Library' [1]:

If a function returns a node that isn't part of an instance:
attaching model item properties to such a node (or one of its descendants) 
is not allowed and will cause an xforms-binding-exception Event.
the node behaves as a readonly node, consequently no mutations are allowed 
on the node or to one of its descendants

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com
www.inventivedesigners.com

1: 
http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_XForms_Function_Library



Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer