W3C Forms teleconference December 14, 2012

* Present

Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox [chair, minutes]
John Boyer, IBM
Erik Bruchez, Inventive Designers [arrived late]

* Agenda


* Delete Semantics

Leigh Klotz: John, I thought you were concerned with the use cases you've put forward but your message said you weren't tied to them.
John Boyer: That might be a misunderstanding.
Leigh Klotz: I think we should look at the delete vs detach idea.
John Boyer: Nick and I talked about deletion and variables; it's very clean. If you delete something without holding on to it, the references drop to zero and the nodes are destroyed. But if you hold on, the way you reference them is through variables.
Leigh Klotz: How does that generalize to iterate?
John Boyer: Because the iterate has grabbed a reference to nodes? I guess that'a a weak reference.
Leigh Klotz: We had also said one ideas was to check at each iteration.
John Boyer: that's another.
Nick van: In the implementations I use, if it can get the context, it keeps working.
John Boyer: If you extend the logic to dispatch (with or without delay) an action after the delete uses a context node, that context would still be there. But if you put that somewhere else and dispatched an even to run the action, it's not in the same action envelope.
Nick van: Then it doesn't receive the context in those implementations. You evaluate context based on where you are.
John Boyer: That's the opposite of the response you gave in the threads. To me tenet number 1 is that there is very late binding, that each action will sort out its context as the first step of running that action.
Nick van: It uses the context in which it runs, not from the document root.
John Boyer: To me that's an implementation detail. You got it from somewhere but the node doesn't exist anymore. You'd think it would work the same: if the node is gone, it's gone.
Nick van: I see actions like functions in programming language; they keep having the context until they return. Same for iterate, like a for loop in an imperative language.
John Boyer: It's like "delete this" in an imperative language.
Nick van: No because delete doesn't destroy a node. On the DOM interface deleting it from an instance only takes it out of the parent, but it's still there.
John Boyer: I guess that's what we're talking about. It's like the fifth Euclidean postulate; there are two valid views.
Nick van: Even in the DOM it's reference counting.
John Boyer: The action immediately after a delete, if that action seeks to obtain its context node only after the delete, then it doesn't have a reference to the node, which means the node would go away.
Nick van: The action already has it.
Leigh Klotz: I don't see how it arises; either the parent action already has it, or it's XPath evaluated against that, and if that consults the XPath model it's not in there.
Nick van: Complete context, also position. So if you delete it from the instance, if it's in an iterate, you also keep the current iteration, but you don't evaluate the context again.
Leigh Klotz: So you should encounter deleted elements in future iterations already underway.
Nick van: Yes, it evaluates to a sequence of items. In iterate you get the first element of the sequence, then the if and while, then execute the action and its children with the new context. Then you go to the next element of the sequence and increment the position by 1.
Leigh Klotz: It's quite clear this is a messy area and that's why XQuery grafted modification on by doing all the updates at the end.
John Boyer: The messiness comes from not recognizing strong vs weak references. When a node is deleted it goes away. If there is only a weak reference such as an iterate context, it goes away.

Nick van: If you have a sequence with 3 items get positions 1,2,3. When you skip one, do the numbers skip? If you delete the last item is it still last()?
John Boyer: That's a good question; I don't know the answer.
Nick van: I see evaluation of context. If you delete the last item then last() will never be true.
John Boyer: Yes, that will cause grief. Also count(following-siblings::.) after you have deleted something...
Nick van: That would change, because it refers to the instance. But we are not updating, I thought, the context once computed.
John Boyer: position is interesting. It's not in the XPath data model any more.
Nick van: But you evaluated the context already. You're iterating over the sequence. So you get last, position, first. In my view, the sequence stays constant. You want to change the sequence while you're looping over it.
John Boyer: I guess that's another possibility to say don't do that or it's not interoperable.
Leigh Klotz: It's not interoperable at the moment. That's the problem to solve.
John Boyer: We don't have @iterate.
Nick van: It was clear in the group that if you delete the context it stops executing but it's not clear in the spec. You aren't constantly checking to see if it's in the instance because that doesn't work in repeat.
John Boyer: Why?
Nick van: If you evaluate an action in an iteration how do you know where it is if you're not keeping track of the context of which iteration it is.
John Boyer: You can ask the repeat: "I'm in 7th repeat item, please give me context node" and it can say it doesn't exist.
Nick van: Then you have to re-evaluate the context every time from the root.
John Boyer: Or we can set the context to null when it's deleted. There are lots of simple ways to implement this, just as the other way. The argument is not what is the easiest way to implement it, but what makes the most sense.
John Boyer: ...
Nick van: ...
John Boyer: Do UI bindings hold on to references to nodes?
Nick van: Until refresh is called, but it depends on whether you hold on to nodes or you recalculate bindings.
John Boyer: We put that explicit wiring test at the beginning of refresh.
Nick van: I was thinking of actions: they don't re-evaluate context until they execute again.
John Boyer: So an action grabs hold of the context when it starts and holds on until it finishes; any actions within it consume that context until that action is over with. A dispatch will cause a new action, separately responsible for obtaining context which it may not be successfully at obtaining? Then the outer action lets go of its context node and it may disappear entirely?
Nick van: That's how I see it works.
John Boyer: Any XPaths that run directly will run over instance data; initial context may come from that node.
Nick van: If you are doing evaluation context with that node it is still there but if you use the instance function, it's gone.
Leigh Klotz: What about ".."?
John Boyer: I think deleted nodes have been detached.
Nick van: Yes, no longer in the instance.
John Boyer: A fictitious node?
Leigh Klotz: What does XPath 2 do with created elements and dot-dot?
John Boyer: It returns the root node.
Nick van: Same as root node. parent::element so dot-dot on root node isn't the document node.
John Boyer: Ok then parent::node(). You don't get back to the node that the element was deleted from.
Nick van: The empty sequence for dot-dot.
John Boyer: And for parent::node()
Nick van: There is no document containing.
John Boyer: The XPath 2 data model allows a root element without a parent.
Nick van: Michael Kay has element creation functions in XPath 1.0 as well.
John Boyer: Good question of Leigh's.
Erik Bruchez: [joins]
Leigh Klotz: I don't care what the answer is as long as we don't cause a new singularity.
John Boyer: In xforms-deleted event context, you get the deleted nodes but you don't know where they got deleted from. It's a bit of a weakness. We said can't we just remove the parent-to-child link but not the child-to-parent link but I have a vague recollection we found that hacky.
Nick van: You'd have to do your own DOM implementation definitely.
Leigh Klotz: We now have a quorum. We discussed a few ideas, such as variables and instance data model being strong references and contexts being weak.
Nick van: But that had a problem with position().
John Boyer: So we thought we could clarify the lifecycle of contexts, and also say what happens with dot-dot at that time. Then if at the end of the action it goes away, would it be before or after deferred updates. A little bit of thought should go into that. The net of that is that the use cases I expressed of deleting nodes in a future iteration case, it would at least be helpful to ask if it's a deleted node so I could tell whether it's a node I should be iterating over.
Erik Bruchez: So a new or existing function would be enough for your case?
John Boyer: If we made the dot-dot clear then I would know.
Leigh Klotz: That works as long as it's not a recursive deletion.
John Boyer: If there's something deeper I can ask a more intelligent question, but in the simple use case it could be a direct parent.
Erik Bruchez: In XPath 2 there is a root function, you can ask for ./root() and that returns the root of the tree. It says "This will usually, but not necessarily, be a document node." So it might be an element.
John Boyer: That call might be implementation-dependent and it might be a difference between XPath 1 and XPath 2. Our XPath 1 engines require a proper data model and I would have to attach it into a new document to use it. There's an implicit assumption that an XPath 1 would always have one.
Erik Bruchez: ./root() instance of document-node()
John Boyer: I could create an extension function, but not(..) is easier.
Nick van: In XPath 1.0 you can't write a function call in the middle of a a path expression.
Erik Bruchez: You can do this too: root(.)
John Boyer: I would expect it would always return a value, not a null. But it's a minor-order wrinkle.
Nick van: If I'm correct it could also check the instance.
Erik Bruchez: Yes, is operator allows identity check. You have what you need in XPath 2 to check to see if a tree belongs to a document. You have to retrofit some of that semantics in XPath 1.0. Even in XPath 2 the assumption is that the data model isn't mutable. XForms is an exception. XQuery and XSLT assume that the data model is immutable for the duration of the transformation or query and you never have visibility into mutations; just the snapshot. Maybe they'll have explicit transactions at some point. In XForms we have XPath applying to a mutable data model without transactions.
John Boyer: This might be a side issue; I think we're close to a resolution as long as I don't have to do the corrections to the spec. If you delete node x and its parent is p and you gain access to node and ask for x/.. should you get p or null?
Erik Bruchez: I would hope that a detached node is no longer pointing to its parent.
John Boyer: Great.
Erik Bruchez: I can quickly check the DOM specification. It says children but it doesn't say whether nodes point to parent.
John Boyer: Even if we were explicit that would be enough: if it says "immediately after deletion if you call .. on that node you will not get the parent element it had before the deletion, you will get null." I think that works because I can still at least do my use case and detect skipping forward iteration and that becomes the explicit language to use. And the implicit use case is where the context hangs around and the clarification there is to say how long it hangs around and Nick says till the end of the action, but we need to say before or after the deferred update. That's a fairly easy spec amendment. And a resolution, and we can do all the use cases with a minimal amount of work and it makes sense. Both models made sense but we just have to pick one.

Resolution 2012-12-14.1: We clarify that immediately after deletion of a node, .. in XPath 2 is () and in XPath 1.0 an empty nodeset.

Nick van: Deferred update isn't using any actions.
John Boyer: I think we should pick a way. I think that's what happens anyway.

Resolution 2012-12-14.2: We clarify a deleted node continues to provide context for the duration of an action that obtained that context prior to deletion, before deferred update.

ACTION-1848 Nick van den Bleeken to update XForms 2.0 wiki spec for deleted nodes in accordance with two resolutions.

* Next Meeting December 21

* IRC Minutes


* Meeting Ends