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]
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.
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]
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.