Erik Bruchez, Orbeon
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C
John Boyer, IBM
Charlie Wiecha, IBM
Uli Lissé, DreamLabs
Steven Pemberton: I will be attending the Model-Based User Interfaces Workshop in Rome.
Steven Pemberton: I need to send a note responding to the comment we received during the AC vote. We hope to hear something today or tomorrow.
Steven Pemberton: Does anyone want to report?
Steven Pemberton: We've got the
dates of the week but I haven't heard which two days we will have.
We did ask for more days.
Leigh Klotz: I'll report back to the
XML-CG call.
Steven Pemberton: Can someone
summarize this?
John Boyer: We're trying to see if
model/@src gives appreciably more power than what we have now or
something like xinclude. Erik and I did our report on what we are
doing. Erik uses xinclude and XBL2. I use "FormParts," which is an
injection. In XBL and FormParts, a key issue is that the IDs are
resolved somehow, and that's a key part of how we get more power
than XInclude.
Steven Pemberton: Resolved means
change to avoid clashes?
John Boyer: In some way, fixed up at
design-time or run-time to make sure that IDs across documents
don't cause a problem. Doing @src or our own version of import
doesn't make sense over XInclude unless we fix that problem.
Charlie Wiecha: In addition to
something over xinclude fixup, there's also multiple injection
points (UI, model) that would be useful.
John Boyer: Design-time Form Parts
does two injections: one to the model and one to a specified point
in the model. For the model, there isn't need for a resolution
within the model.
Leigh Klotz: I guess for
document-order in the model we have only the first instance.
Philip Fennell: Anything you inject
would have to have its own ID.
John Boyer: There are possibly
subtleties about event handler action ordering but I don't think
people are depending on that. For runtime, the composite control
might fit in the UI layer, and would contain UI and Model content,
and its model wou have to communicate with the
containing-document's model. So it's the runtime analog of not
caring where it goes in the model.
Leigh Klotz: One of our engineers,
Julie Craig, has implemented a deponent XBL2 processor, following
on the fuller experience of Erik with XBL2. It took about half a
day and works nicely, at least so far. I'll report back if there
are issues.
Charlie Wiecha: Do you do ID
fixup?
Leigh Klotz: You let the user write
parameters and it just works. The form author knows the document
and knows the binding points.
Charlie Wiecha: How about using XSLT
gensym for creating ID nodes?
John Boyer: That can be a problem for
documents.
John Boyer: Leigh's suggestion may or
may not work at the moment for this but I think these problems can
be solved.
Steven Pemberton: How about an
instance and another department produces bind/@id for you?
Nick van: Then you can use XInclude.
It's your API you are defining.
Steven Pemberton: As long as nobody
clashes on IDs.
Steven Pemberton: So what are next
steps?
Leigh Klotz: I'll write up the work
we've done and I think Steven should say whether he still thinks
model/@src or import is necessary, or if there are other use cases
that aren't solved and we want to look at into it.
John Boyer: Something over xinclude
you mean?
Leigh Klotz: Yes or an equivalent
inclusion, server-side.
Steven Pemberton: I'd like to have
something interoperable so you could how to package models.
John Boyer: It's a little like XML
Events; not in the XForms namespace but you need to do them.
Leigh Klotz: We should review the XML
Processing model for XInclude.
Action 2010-04-21.1: Leigh Klotz to describe deponent XBL2 used for XForms macros.
Action 2010-04-21.2: Steven Pemberton to describe use cases for inclusion not handle by XInclude or deponent XBL2.
Nick van: As we discussed at the
F2F, a function for doing xslt() would be a nice thing to have.
Claudius came back with an implementation and there was a question
about the stylesheet, which was just a URI. I also pointed out it
was supported in other implementations as a node, or in the
instance. Also Saxon offers a compile and an execute, for
performance reasons. If you have variables, you can keep the
compiled version around. With URI only, you can cache it, but if
you have the stylesheet in your instance data, it's hard to
cache.
Leigh Klotz: I also suggested
privately that he use fragment URIs for id references in the host
document.
John Boyer: Isn't this a rather large
addition to XForms?
Leigh Klotz: It's community feedback
and possibly an extension function. At the F2F we asked for him to
propose a function instead of an action.
Nick van: It's not a big deal to add
to Java-based implementations. It's probably harder to implement on
small devices.
Leigh Klotz: It could be very popular,
as it would be easy in Orbeon, BetterForm, XSLTForms (already
done), and Ubiquity. So I think it's in our interest is to make
sure that processing model doesn't get broken and I think we need
to provide the group's expertise.
John Boyer: Would this be an optional
feature?
Leigh Klotz: Or maybe just an
extension module we publish.
John Boyer: What's the return
value?
Nick van: A node.
John Boyer: But it's not in an
instance.
Nick van: Neither is event
context.
Erik Bruchez: Or the XPath 2.0 doc
function or node creation functions.
John Boyer: So we have to deal with
it. An calculate would have to deal with it. If you put this in a
ref it would run often.
Leigh Klotz: You mean in a bind
calculate?
John Boyer: No, a bind ref (not
nodeset).
Erik Bruchez: We have a function that
returns whether a node is in an instance.
Leigh Klotz: So what happens when you
use bind on one?
Erik Bruchez: Nothing special, I
think. We set MIP properties but not much happens.
John Boyer: I think about
input/@ref="xslt()" or @ref="create-node()".
Erik Bruchez: We used that trick for
repeat, for example iterating from 1 to 10. The problem was that at
every refresh, all iterations were re-created. It worked, but it
wasn't efficient. We changed to support repeat iterating over
atomic values in XPath 2.0, so we do 'repeat ref="1 to 10"' as an
extension. So you are right, it can have funny implications. We
could say it's not allowed, or we could say that if you do it, you
could have unusual consequences.
Steven Pemberton: Possibly it is
non-interoperable?
Leigh Klotz: I think the slow refresh
turned out from the definition.
John Boyer: Or there may be some
deeper issues we should have already figured out to avoid support
calls.
Steven Pemberton: This is an
eye-opener for me on the design process and cost.
Steven Pemberton: So back to the
xslt() issue. What do we do?
Leigh Klotz: We point out the input
ref and the bind nodeset (ref) questions and suggest the repeat use
case might be slow, due to experience.
John Boyer: He pointed out you
suggested submission ref.
Leigh Klotz: submission/@ref=xslt()
submits the result of the transform.
Steven Pemberton: He also wants it
during the form filling.
John Boyer: The action version seems
to have clearer processing as the data is always in an
instance.
Nick van: But the
submission/@ref=xslt() case is many, many steps.
John Boyer:
submission/@ref="instance(xslted-output) and an event
hanlder.
Nick van: There are a couple of extra
actions and an extra instance.
John Boyer: One instance element and
one event handler.
Nick van: A second action to void the
instance to reduce memory.
John Boyer: Assuming you throw away
the data once the submission is completed.
Nick van: It goes away.
John Boyer: It's syntactically easier,
but it introduces problems elsewhere.
Nick van: As Erik pointed out, and I
said in email, the attribute() creation function is handy. We have
the same problem with the element() function.
John Boyer: That's true.
Nick van: We need to see how much it
is used; if it's rare, we don't have to make it easy.
John Boyer: I thought the node
creation functions would be specific about where they could be
used. Maybe we need to say the same about xslt(). We've had
functions that produce errors in certain places. I.e., a binding
exception in a UI binding.
Leigh Klotz: How about in a predicate
of a UI binding? The data is never seen, but there's still the
runtime problems.
Nick van: The runtime refresh.
Leigh Klotz: If it has no side
effects?
John Boyer: If you use it in a
predicate, you'd have to collect additional nodes used out of thin
air and sticking them in dependency lists. So the nodes could hang
around forever.
Nick van: ...
Leigh Klotz: You can't examine the
XSLT for nodes because it's Turing complete.
John Boyer: We can track what it
returns. In general, functions should operate only over their
parameters. The node creation functions have that property. All
that gets tracked is the parameters and the results. Inside is a
black box.
Steven Pemberton: Where do we
go?
John Boyer: The xslt() function is
more sophisticated than the element creation functions. You can
achieve the same effect with the action but it's wordier.
Nick van: I think it depends on where
you allow the function and it's much easier.
Steven Pemberton: So it brings
concomitant dangers.
Leigh Klotz: Or you can say you cannot
use it in binding expressions.
John Boyer: UI or model bindings. Only
used in submission or action.
Leigh Klotz: How about repeat?
John Boyer: That's more
problematic.
Steven Pemberton: What do we do
next?
Leigh Klotz: We asked Claudius for the
function, and now we see problems. We should decide if we want to
pursue it, or if we want to recommend going back to the
action.
Steven Pemberton: So it's our first
agenda item for next week.