W3C Forms teleconference November 30, 2011

* Present

Steven Pemberton, CWI (chair)
Leigh Klotz, Xerox (minutes)
Alain Couthures, AgenceXML
John Boyer, IBM
Nick van den Bleeken, Inventive Designers
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon [joined late]

* Agenda


* Administration

Steven Pemberton: I won't be here in December.
Steven Pemberton: There is also "Error Handling in XForms" from Erik Bruchez, http://lists.w3.org/Archives/Public/public-forms/2011Nov/0027.html
Leigh Klotz: We can discuss that when Erik is here.

* Editorial Meeting

Steven Pemberton: Nick and I have an editorial meeting tomorrow and the next day.

* XML Prague, February 11-12

Steven Pemberton: XML Prague submission deadline is midnight tonight, Pacific time.
Alain Couthures: The week before the rooms are all booked, and after is difficult to get a room.
Steven Pemberton: So do we just have to not do it?
Alain Couthures: Or we should find something on our own.
Steven Pemberton: I've committed to going, as long as one of my abstracts gets accepted. And we can have a meeting on the Friday before.
Alain Couthures: Community Day

* Grant Solutions

Steven Pemberton: "We have been using XForms for some time now and are continuing to make investments in the technology." I've asked for more details.

* IBM Forms Release

John Boyer: Our new release is out last week; XForms has a larger role. IBM Case Manager, for Advanced Case Management (insurance claims, product warranty defect claims, dispute resolution for credit card charges, medical case claims), things that involve a step-by-step process with lots of people. Someone builds a system that defines the pieces of data and the conditions under which they branch and flow. It's like workflow, but without the full complexity: it's targeted as business analysts rather than workflow engineers. These advanced solutions often need a document of record to be created. The IBM Forms Solution uses XForms to create a document to be printed or digitally signed, and we created an integration between IBM Forms Solution and IBM Case Manager. A piece of code generates XForms type bindings, relevance bindings, instance data, dropdown lists, etc, that are dynamically injected into XForms from the Case Manager solution. They use their own internal storage for types and constraints, but to impose them by IBM Forms, they inject binds, and our Form adds more constraints and adds value. We take heavy advantage of the new direction to allow XForms processors to combine multiple MIPS together; additional XForms binds over the same nodes are handled by the processor together as we documented for XForms 2.0. We needed that capability and now we're using it.
Steven Pemberton: When will this be released?
John Boyer: It was electronically available last week. There will be an announcement.
Steven Pemberton: We'll put the announcement in the news.

* @iterate


Leigh Klotz: Central issue is what to do with parent-less nodes, which are ignorable in XPath 1 but not in XPath 2. So XPath 1 implementations may skip action sequences where the context node is parent-less, but XPath 2 need not.
John Boyer: I don't recall saying you'd skip nodes that don't have a parent; you'd skip nodes that are deleted. Nick asked and I said no, I mark nodes as deleted. We use a separate flag for that. We don't have any processing that we support for nodes that are orphaned, but that's beside the point. We have independent representation of nodes that are marked by for deletion. The toplevel action sequence has finished.
Nick van: What is the reason that you need it? I know two implementations that don't have that flag.
John Boyer: They could can do it even if they don't have it now.
Nick van: Is there a good reason?
John Boyer: I really felt that the XForms commands must be issued; if the node is deleted, further processing on those nodes must cease. If someone cleans them up later, that's good. When you do an iterate, you might decide to delete some nodes and I think the iterate should naturally come to the conclusion that the iteration shouldn't happen over deleted nodes. It's either deleted or not.
Nick van: I always thought that the XForms delete action was a way of removing it from its tree and nothing else, but perhaps I'm biased by our work in Java.
John Boyer: To me, I look at delete as gone, no longer there. Now @iterate has held on to a pointer to it. Someone wrote a method.
Leigh Klotz: It's not just iterate; in action, you can delete the context node.
John Boyer: The only following action are ones that don't require a context node.
Leigh Klotz: I wonder if we should have a delete and a detach, as in JDOM?
Steven Pemberton: Can't we first put it somewhere else and then delete it?
John Boyer: That's what I do; I first insert it somewhere else and then delete it.
Nick van: You can't reach the node once you delete it.
John Boyer: It is in the context info, but let's pretend it isn't: iterate still has a pointer to it, or some implementations might.
Nick van: If you get it in your context and you insert it then delete doesn't.
John Boyer: An XForms delete handler can only use it as an origin and insert a copy elsewhere. There's nothing in XForms that lets you operate on it.
Nick van: You can copy.
John Boyer: After the delete is finished, the default processing does that. This part of complexity is why we don't have @iterate in the first place in XForms 1.1. It's like we don't have the nodes; it shouldn't be able to iterate. Perhaps it should take them out of the nodeset; that's one reasonable implementation. Another is to ignore them if you encounter them in an iteration. Whether you ignore them or not actually makes a difference. If they aren't automatically ignored, then I need some way to ask if it's a deleted node, which seems like a ridiculous question to ask.
Nick van: In your action on iterate, you are deleting the following statements.
Leigh Klotz: Only if they don't refer to the context node.
John Boyer: In sort, I find the least-valued element. Then assuming duplicate keys, I assuem every nodes that matches that key, I copy. That causes me to delete duplicate keys, so future steps will only copy higher-valued key values.
Steven Pemberton: So what you mean is that it sort of works as you would expect it to even though something funny happens in the middle.
John Boyer: Yes, I copy all the values out in that first iteration.
Nick van: In both Chiba and Orbeon, if you delete the parent of the context node, everything keeps running and you can still do meaningful things elsewhere in the instance. But in your implementation, can you still work over the detached node on the deleted tree or do you stop all the actions?
John Boyer: The iterate itself decides to skip over nodes marked for deletion.
Nick van: And if you delete an ancestor of that node?
John Boyer: The deletion of some ancestor is what Leigh was mentioning before; it's an unrelated issue. If I remove the entire context of evaluation, more or less everything stops and the processor backs out until it can regain context.
Nick van: Is that somewhere in the spec? I'm quite sure I know of implementations that keeep running and you can insert in other parts of the tree.
John Boyer: We might find some language to that effect, but it's an inherited behavior of XPath 1.0, which requires that you have a context node.
Nick van: But if you delete an ancestor you still have a context node, but one whose parent is not rooted in the original document. The data model is not mutable in XPath.
John Boyer: Until iterate, we didn't have any way for nodes to survive past the delete event.
Nick van: Starting from XPath 1.0, you can have actions in a sequence. If the action deletes an ancestor then the action keeps on running, and if you use the instance function you can go back to the original instance because you still have an evaluation context.
John Boyer: That is the XPath 2.0 interpretation; there is none for XPath 1.0.
Nick van: So the spec says it removes nodes, but it doesn't say the nodes aren't there any more. You can copy them in your implementation so they aren't gone, so you have an evaluation context.
John Boyer: I made an assumption; I assumed they were gone with delete.
Nick van: I implemented it by removing nodes from the instance data, but not by destroying them. Eventually they will disappear when nobody points to them. Deletion isn't destruction.
John Boyer: When you end the delete, nothing is pointing at them any more.
Nick van: The action is in the evaluation context.
John Boyer: That depends on how you implement it. Another implementation of an XForms processor would use delete and the first thing after is to obtain the evaluation context. Another interpretation is that all nodes have a pointer to their context at all times and deleted nodes would never cease to exist.
Nick van: The evaluation is based on the parent's evaluation context. So you could still get it. Both interpretations do something different.
John Boyer: We have no hope of interoperability if how it works depends on on weak vs strong references.
Leigh Klotz: We've already established we have no interoperability and we need to decide what to do in XForms 2.0.
Nick van: John's is more intuitive but in XPath 2.0 you can run without an evaluation context, for certain functions.
John Boyer: Such as those that start with instance. I would have thought that those would continue to work in XPath 2.
Nick van: To be clear, it's a bit of a border case.
John Boyer: It overlaps into the original issue of @iterate. Within an iteration, if you look at all the actions within the body of the iterate, effectively, you've deleted the context node for that iteration of the loop body and as a result the loop body shouldn't run.
Nick van: It requires that implementations which don't do it yet to do more. They have to walk the complete subtree.
Steven Pemberton: So what is the visible difference between the two approaches.
John Boyer: If you have a list of elements that contain a key value, where some elements contains a duplicate value, the simple sorting approach with @iterate finds the minimum value and takes all occurrences and moves them someplace else, the moves to the next node. If iteration is allowed to operate over deleted nodes, then I'll be taking a copy of those nodes again. The bottom line is that for a particular implementation, it will matter whether a particular implementation makes multiple copies.
Nick van: this works in both approaches : <xforms:delete nodeset="." at="1" iterate="node[@selected=true]"/>
Nick van: but if you delete nodes that are __after__ your current position of your current iteration you get a difference
Erik Bruchez: [joins]
Nick van: The net result is different if you delete future iterations.
Leigh Klotz: Are you deleting the exact node, or some child or parent?
John Boyer: See http://lists.w3.org/Archives/Public/public-forms/2011Oct/0015.html
Leigh Klotz: So it is deleting nodes that are top-level elements in the nodeset.
Nick van: That deletes nodes that are to be visited in the future as well.
John Boyer: The innermost iterate copies them all and the outermost will come across the already-deleted ones again.
Leigh Klotz: Is it possible to re-write this to copy only one person with [1]?
John Boyer: Yes, but it's not as intuitive and it's hard to tell people how to write it.
Leigh Klotz: How about we do as in Java and allow a way to delete the current node from the iteration.
Erik Bruchez: Maybe in John's implementation delete obliterates, but at least in XPath 2 you can still work with them. I would hate to limit modifications to past items. However, I would also consider that we look at the iteration as a lazy stream. So the future items could be determined lazily; if you process one and run the nested action, you can then decide at that time what is the next sequence. I wouldn't like that very much but I can see how you could build something that holds water. Past items have already been computed, so it doesn't matter what happens to them.
John Boyer: http://dictionary.reference.com/browse/delete to strike out or remove...; cancel; erase; expunge
Erik Bruchez: It's only about the future items.
John Boyer: I made the statement that delete has a particular meaning and we can't change the meaning of the word delete because it's expedient for us. They are expunged. If you want detach that's a separate action we don't have.
Steven Pemberton: If I understood what Erik said, you can delete it from the place where it's gone from but you're still deleting from where they came from.
Erik Bruchez: Even if you adhere to a strict definition of delete, the parent will no longer see the node, but that is consistent with John's definition. Even if you have such a definition, it's not taking us anywhere. You can show that implementations work with detached nodes. Either way it's possible. I don't think we're arguing that one way is impossible; both have benefits and drawbacks. The question is which one is in some way saner or more consistent. My point of view is that I don't want to specify somethign that is known to be a problem: Leigh mentioned Java deletion of only the current node in Java. In Scala they don't allow that. My perspective is that changing stuff under your feet is dangerous. By keeping stuff as references at least you are not changing the expectation that the list will change. So I think it's hard to decide and I'm not convinced either way which approach is the sanest. What XQuery does is more sane. You reduce everything to a changeset and there's no mutation going on at all while you're running the code: the mutations would be invisible until the end and everything is committed to the DOM. John's example would have to be written a different way but that's ideally what should happen. Barring that, we should try to keep from changing things under our feet.
Nick van: In xpath 1.0 you can set the context node to the deleted node, because it is a node nd you can create an xpath data model from it, but it is all a bit beside the point, we need to make a decision of what we think is the best. If we can't come to an agreement we should leave it undefined.
Leigh Klotz: I don't want to leave it undefined. We should define how it works in XForms 2 and XPath 1 and 2 and not try to change XForms 1.1.
Nick van: What we do here has an effect on actions whose parent aren't deleted.
Leigh Klotz: I think we need to look at this through the cold hard lens of XForms 2 users and XPath 1 and XPath 2 implementations and see if detach vs delete works, or if we need to prohibit iteration deletions except to the current node via a specific action, or if the XQuery change-set approach works (which I don't think it does).
John Boyer: The first line of delete says that it's been deleted from the instance data. It's not allowed.
Erik Bruchez: Actions are allowed to work with other things. Parse, node creation, local variables in other instances.
Nick van: The event function returns nodes which aren't in an instance.
John Boyer: If they're part of the data, they're either there or not.
Nick van: It says nodes are deleted from the instance, not the nodes are deleted.

Steven Pemberton: I'd somehow hoped we'd manage to find a middle road today. Leigh you had a proposal for going forward.

Leigh Klotz: I think there are two interpretations that are incompatible in XForms 1.1. We can't fix that. But For XForms 2, we should come up with with a set of use cases, and evaluate proposals for how to alter the expressions of those use cases so that they can be satisfied with XPath 2 and with XPath 1 (at least for those expressible in XPath 1, which is mostly John's concern) and then see if we can come up with a clear, consistent model for XForms 2 that encompasses them.
Steven Pemberton: OK, so John has provided one use case. He can provide more. Erik and Nick can you provide use cases?
Leigh Klotz: Of things that you can't do if delete made nodes unusable in actions?

ACTION-1846 Erik Bruchez and Nick van den Bleeken to come up with delete/detach use cases.

* IRC Minutes


* Meeting Ends