Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox [chair, minutes]
John Boyer, IBM
Erik Bruchez, Inventive Designers [arrived late]
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.