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

Hi John,

Thank you for the fast response. I think it is best that we put this on the agenda of one the next calls, because I'm not 100% sure that I understand what you are trying do with the associations.

In my mind nodes that are part of instance are 'special' nodes to which you can attach MIPs. Nodes that aren't part of an instance (i.e.: the root node of the node isn't the live instance data node) could be nodes of any kind (which implement the XPath node interface) but don't necessary have the ability to hold MIP information.

I don't think that we can require that an implementation is able to attach MIPs and support mutation of all the nodes a function returns. An implementation could for example have a function that returns the host document, or implementation dependent information.

I don't completely get your associate proposal, in my mind you can only 'associate' a node to an instance by inserting it into a live instance, by which you easily know at runtime when a node is part of instance (you can get the root node and/or owning document). If we really need a way to dynamically create instances we could probably better have a function to create/request a dynamic instance (maybe as simple as an optional parameter on the instance function, create-if-not-exist). This would be a small change and would solve the same use cases as the getAssociation and setAssociation function, if I understand your use-case correctly. But I think it would be better to discuss this on a teleconf.

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<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 30 Jun 2011, at 18:55, John Boyer wrote:

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<mailto: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<mailto:Nick.Van.den.Bleeken@inventivegroup.com>>
To:        Public Forms <public-forms@w3.org<mailto: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<mailto: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<http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_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<mailto: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

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

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