W3C Forms teleconference October 19, 2011

* Present

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

* Agenda


* Progress

Steven Pemberton: Maybe it's time for for Nick and I to organize another Amsterdam meetup.
Leigh Klotz: You doing all the work sounds fine to me but not entirely fair.
Steven Pemberton: We've had one here, then one there. Nick and I have been at both.

* Aeronautical Information Services (AIS) and XForms


Steven Pemberton: "running in a standard web browser without any plugins. not a single line of script code was necessary to implement the forms"
Leigh Klotz: I see they're using xf:load/@show=embed which I hope Alain will be putting into XSLTForms.
Steven Pemberton: I'd like to scroll, say Google maps, by grabbing.
Leigh Klotz: Didn't Mark Birbeck do something like that with a control?
Steven Pemberton: He used range.
Leigh Klotz: Two ranges?
Steven Pemberton: I think range was bound to two values.
John Boyer: Three values -- the zoom.
Steven Pemberton: That's a separate control.
John Boyer: It could be X, Y, Z range. Then you need a component technology.
Steven Pemberton: You can only focus on one control at a time. For a map, if you're focused one control it would have to move in two dimensions. You'd need a three-dimensional control.
Leigh Klotz: And scroll bars are one-dimensional.
Steven Pemberton: We say range binds to single number.
John Boyer: Yes
Leigh Klotz: We have no complex bindings, but upload is odd.
John Boyer: We use child elements. We also do that with itemset to bind a control to two separate sets of data. In upload you can manipulate multiple data elements with essentially the same control. More than one control uses child elements. If you squint at repeat it is kind of the same idea. Maybe multiple child elements, or a different range. Child elements may be the way to go.
Steven Pemberton: That's what I really meant. It means a change to the language.
John Boyer: Right
Leigh Klotz: Is there some child element we already have that we could just allow multiple of, kind of like label?
Leigh Klotz: how about range with no ref and two child elements? <range> <label>The Hand</label> <input ref="lat" /> <input ref="lon" />..</range>
Steven Pemberton: That might do it.
John Boyer: Which is which? It's a little better with upload because the child elements have names that are suggestive of what they do. You could see a range control here with latitude, longitude, zoom, and whatever else, but at some point it isn't a range anymore.
Steven Pemberton: That's because you're thinking of a map. It could be a photograph.
John Boyer: Is this presentation or an input control?
Steven Pemberton: You capture mouse X and Y at the same time, and the mouse is as 2d input device.
John Boyer: And zed.
Steven Pemberton: It should be generalizable.
Leigh Klotz: Like a Kinect?
John Boyer: I don't care about the mouse, but the top-left corner of the map.
Steven Pemberton: Then it's the same as a range. The map is the presentation aspect.
John Boyer: The map could come from another child element, output/@mediatype="image/*".
Steven Pemberton: Typically you use more than one image at the same time.
John Boyer: Yes. If you point, click, and drag to the left, and let go, what do you store in the instance data? The let-go spot? The top-left corner?
Steven Pemberton: It works the same as range; does that answer your question?
John Boyer: If I click and drag again, what goes into the instance?
Steven Pemberton: It adds or subtracts as you move. It's not absolute values.
John Boyer: But it's an absolute value that you're authoring. Then I could save those.
Steven Pemberton: That's exactly how it works. You can do this in XForms now except for the XY slider. I have some example applications using it, but XSLTForms doesn't have range so I have to use nudge buttons rather than sliders.
John Boyer: You could prototype it with xf:group/@appearance="my:map" and have a range control for x, y, z.
Steven Pemberton: XSLTForms doesn't have range. You can put ranges on the left and right and zoom. That's not a problem. What we're missing is the ability to do the X-Y slider.
John Boyer: With the group, the ranges are intent-based UI controls, not a literal representation of the screen. They might presentationally display using a map-like construct.
Leigh Klotz: So group/@appearance is a component.
John Boyer: Something like that. You manipulate X, then Y. It's single-threaded.
Steven Pemberton: XForms doesn't allow two controls to have focus at the same time.
John Boyer: The best that can be said is that the group has focus.
Steven Pemberton: You're getting to a construct where we have a control element with child inputs..
Leigh Klotz: And outputs.
Steven Pemberton: ...which would be the way of doing multiple controls.
John Boyer: Then we have to identify which is X and which is Y and zoom. You can use @appearance="latitude" for your prototype.
Steven Pemberton: Yes, as for a prototype Mark did it already. I want to show the power of XForms. I don't usually like to show extensions.
John Boyer: To some extent that means appearance is out, generally speaking.
Steven Pemberton: I guess.
Nick van: [joins]
John Boyer: You're supposing to add a range extension. XSLTForms would make a slider if you added it. You need a higher level to show they are working in unison.
Steven Pemberton: When we originally designed XForms we unified several and named others. This has become a control that's widely used but we don't have an official way of representing it.
John Boyer: We keep hitting this. We need compound controls. I want 4 inputs (or 6) for an Internet address. Or the CC#. Some of that stuff turns out to be really hard to do, to let multiple focusable things do one thing. You could readily see three separate controls for x/y/z, but they don't have to be separate elements. It could be one range/@appearance="map" with @ref a space-separated list of coordinate values. So I think you don't need separate elements.
Leigh Klotz: The space-separated list of locationpath expressions is interesting but a little scary.
John Boyer: Yes
Steven Pemberton: It seems to be cheating a bit. Really it should bind to an XML-style list.
Steven Pemberton: We did it because that's what servers would expecting at the time.
Leigh Klotz: Oh, I thought you meant ref="a b c".
Erik Bruchez: [joins]

* Thoughts on @iterate

http://lists.w3.org/Archives/Public/public-forms/2011Oct/0015.html http://lists.w3.org/Archives/Public/public-forms/2011Oct/0009.html

John Boyer: Earlier in the thread, in my message, I put in some answers for the three discussion points.
John Boyer: The first was combining @iterate with @if and @while. We asked whether we should forbid it or specify it. I've been doing work to implement this recently. I think the order is action, @context, @iterate. That provides context for everything else. @while and @if claim they use the in-scope evaluation context, but we should say that @iterate iterates everything but @context and the @while and @if should be regarded as inside the @iterate.
Leigh Klotz: I think that's the only consistent order we came to, but since that's easily expressed by doing a nested action.
John Boyer: It could be done with MAY.
Leigh Klotz: That doesn't sound interoperable.
John Boyer: It's harder to implement all on the same element, so in the interest of expediency we will throw an error.
Leigh Klotz: My argument was that it was confusing; people might try to control the oder by controlling the order of operations. But if it's also harder to implement, let's just say no.
John Boyer: It's a day vs a week.
Leigh Klotz: I did a prototype implementation in two hours and I forbid it too.
John Boyer: It seems confusing to authors, but some may want it to work.
Leigh Klotz: I'm pretty opposed to MAY; it's a bland-looking form and it ought to work or not.
John Boyer: Does anybody actually care to put them on the same element?
Erik Bruchez: In our implementation we have @xxf:iterate and it does support the combination and it does owrk for us now in combination. I don't think anybody is using that. I don't have very strong feelings. It depends on what we say. I don't care about @iterate and and @while. I have more reservations about @iterate and @if, as that might be more convenient. But I could go either way.
John Boyer: Are the @while and @if evaluated according to the iterate node or the cotnext node?
Erik Bruchez: I'll have to look at the code as we don't document it.
Leigh Klotz: Isn't that what you get with nested action?
John Boyer: Yes.
Erik Bruchez: That's what we do as well.
John Boyer: It makes sense, but the additional effort to make this work is only a few days. Perhaps we shouldn't create a limitation in the spec. Why limit the combination when it's relatively easy?
Leigh Klotz: What happens when you target an event at a nested action with an id.
John Boyer: An @iterate with nested actions inside? I guess the action runs independently outside the iterate. It's a question for @iterate but now how they work together.
Leigh Klotz: If we defined the combination as being equivalent to nested actions, then you have this problem. It's not equivalent.
John Boyer: When @iterate is on the same element as @while and @if it duplicates the rest of the action less @context and less @iterate. It's slightly different than nesting. We've fallen into that trap before; it's not exactly the same, but we still have a well-defined behavior.
Leigh Klotz: We have to describe it as what it does, rather than it does something like.
John Boyer: So MAY is out but we know what using them in combination does.
Erik Bruchez: There could certainly be a note about order of attributes not mattering.
Leigh Klotz: I don't think that anyone who would be confused by that is going to read our note.
Erik Bruchez: It's definitely a confusing thing. Our implementation is straightforward. It would be more work to prevent them from working. There's no code complexity for the implementor, only the author.
Leigh Klotz: If you take that argument to the extreme, you wind up with Forth.
John Boyer: I see people adding parentheses all the time with AND expressions for clarity. I think people will use nested expressions for clarity.
Leigh Klotz: I can live with whatever everybody else wants.

John Boyer: The only real discussion was on point 2 (and a little on point 3). If you identify an @iterate nodeset, you identify it once. If someone adds to or deletes from the nodeset then you still iterate over the identified nodeset. If you delete future nodes, that's a supported behavior and it acts as if those nodes don't exist.
Nick van: How can you implement that? If they are in a document or not why does it matter?
John Boyer: While it is true that I don't have orphan node functions, that's a side issue. We have an extra boolean flag that identifies whether a node has been deleted or not, not a parent. Our implementation does that. It's a trivial one-bit flag.
Nick van: If you delete the node from one instance and move to another in an iteration is it still removed?
John Boyer: When you insert a node into another instance that's a different node.
Nick van: And the same instance?
John Boyer: It's the same case. We don't have a "move."
Nick van: If you delete and insert again it's copied?
Erik Bruchez: I think it could cause problems with namespaces. I don't know what happens.
Leigh Klotz: The namespace of a node is an external URI. It is retained when moving. But I think C14N doesn't consider namespace prefixes.
John Boyer: If I want to move all matching elements and move them somewhere else, if I grab them, insert them, then I need iterate to ignore them.
Erik Bruchez: In Java and JavaScript, the easiest implementation is when you delete a node from a tree and detach the node, you cut the relationship and the node is still there. You can still navigate. That's pretty much the default behavior. Deleted just means removed from where it was attached; inserting again may mean a copy. You'd have to mark the nodes. To cover your scenario, you could imagine saying that if the node has an owner instance, or a document, maybe there's another way to handle it. I think it's dangerous to have iterations that modify along the way. For example, in Java, you get exceptions.
Leigh Klotz: They do address the use case in Java by allowing ListIterators which can remove the current item.
Erik Bruchez: Yes, Scala has no side effects in iterators. Being able to remove the current node sounds useful, but future nodes is scarey. I think it wouldn't be unsafe if you did it with future nodes, but it adds complexity. I don't see a good reason for the general case, but I do see some use cases where it might make sense.
Nick van: What happens when you delete the parent node?
John Boyer: That stops the whole action sequence because of lost context.
Nick van: With every deletion you mark the complete subtree?
John Boyer: To indicate that you have deleted it, yes.
Leigh Klotz: We're over time.
John Boyer: I won't be here next week.

* IRC Minutes


* Meeting Ends