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]
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.
Steven Pemberton: Nick and I have an editorial meeting tomorrow and the next day.
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
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.
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.
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.