Alain Couthures, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
Steven Pemberton, CWI (chair)
Nick van den Bleeken, Inventive Designers
Steven Pemberton: It's now a
priority to get FPWD out in the coming weeks. We need to formally
publish what's in the wiki.
John Boyer: I have a bunch of action
items, but they don't all need to be done before FPWD.
Steven Pemberton: Right. We could have
an action item to look at the draft as it is and see if there's
anything that we think blocks it.
Leigh Klotz: Is there just one
document?
Steven Pemberton: I guess it's several
documents. I'm primarily talking about the XForms 2.0.
Leigh Klotz: Like the modules.
Steven Pemberton: XPath expressions
has been modularized but that's all.
John Boyer: That's correct.
Leigh Klotz: So we need to decide what
to do with that.
Steven Pemberton: So lets' have that
be the main agenda item next week.
Steven Pemberton: Michael
Sperberg-McQueen has written a P-Code interpreter in XForms. I
wrote a book about the P-Code interpreter in the 1980's. For me,
the principal reason that it's interesting is that it shows that
XForms is Turing complete.
Leigh Klotz: I think it has some
JavaScript.
Steven Pemberton: Ah, I didn't check
that.
John Boyer: It's Turing complete: we
have loop, insert, delete, if. Our memory model is very
sophisticated. I did a blog post on sorting. The efficient one was
stack-based using insert and delete.
Steven Pemberton: There are three
functions in JavaScript: xsl:id, which isn't of
import. describe-object which is probably only for
output. And the third is bmt-base, some function,
which says for debugging.
Steven Pemberton: I will be
there.
Alain Couthures: I will as well; I
will talk about XQuery and JavaScript.
Steven Pemberton: We can't have an
official meeting but we can have presence.
Nick van: I will arrive late
Thursday.
John Boyer: This blog entry explains what Advanced Case Management is. We're using it with XForms as I described a few weeks ago.
Steven Pemberton: Is it in for
class?
Leigh Klotz: So we left where it works
to host-language integration.
Leigh Klotz: John's use case is satisfied by noting that if the item is removed from the immediate parent then ".." is empty.
John Boyer: If you make an
xf:action under xf:repeat, does it listen to events on the repeat.
Erik gives two possibilities: no, it listens on the implicit
xf:group, and yes, it listens on the repeat. We had decided it was
option A, during CR. Perhaps it's not made clear as I thought. The
handler is set up during runtime on the xf:generated group for each
context node the repeat is handling. If you wanted to listen on the
repeat element itself, you would have to place the action outside
the repeat and use observer attributes. We included an example
saying how to listen for events on a repeat, and that is in the
spec. I thought the wording about repeat object initialization was
clear enough; we might add "those handlers listen to the group
generated to represent the repeat object" but we didn't go that
far.
Steven Pemberton: What do we need to
add to the spec to make that clear. Can I ask you to propose some
text?
John Boyer: I thought it was clear.
http://www.w3.org/TR/xforms11/#ui-repeat-processing
John Boyer: I will make it clearer
though.
ACTION-1853 John Boyer to clarify http://www.w3.org/TR/xforms11/#ui-repeat-processing to match implied example about events.
Leigh Klotz: There has been some news on Shadow DOM. You might want to read it.
Steven Pemberton: Should we do this
differently because of @ref?
John Boyer: We already have this
feature, as a structural change with insert and delete. That makes
it easier to track. So typically, today, if you need to add an
attribute, you do insert/@ev:event=xforms-model-construct-done with
@if depending on whether it exists.
Steven Pemberton: We've had this
discussion and it's an obvious use case, so it's a pain to have to
say it programmatically. It's just not pretty and is a frequent use
case.
John Boyer: You'll write either a bind
with an initial value, or you write an insert and three attributes.
It's about one element's worth of work no matter how you do
it.
Leigh Klotz: I think Steven is
agreeing that it's syntactic sugar.
John Boyer: The headache is that MIPs
are always applied; this one is applied once.
Leigh Klotz: This isn't a MIP. Maybe
it's a child element under bind.: <bind
ref="foo"><value>123</value></bind>
Steven Pemberton: Some implementations
have this already.
John Boyer: That doesn't mean it fits
well with the overall design.
Steven Pemberton: But I'm convinced
that it's a standard use case.
John Boyer: If someone deletes it
later does someone it come back?
Steven Pemberton: That's a
detail.
John Boyer: A MIP is always on, always
applied.
Steven Pemberton: This is instance
initialization.
John Boyer: Today we use
xforms-model-construct-done handlers.
Nick van: Or we use lazy authoring.
Also MIPs apply to nodes that are already there and this is
different.
Steven Pemberton: I already wrote that
it's not a MIP.
Leigh Klotz: What happens if it
matches more than one node?
Nick van: It will add to all the
elements.
Nick van: We have this in our product;
it gets harder when you want to do more.
John Boyer: It might help to know more
about the use cases.
Steven Pemberton: Maybe we can ask
Erik to describe his.
John Boyer: There are a number of
potential technical requirements: xforms-model-construct-done at
form startup. How about when an instance is loaded with instance
submission replace? Where are the spots?
Steven Pemberton: I agree the
questions need to be answered. But the base question is how it
should be specified and we can define under what situations it gets
executed.
John Boyer: That's designing the
answer first.
Nick van: I can give you a use case.
In an early version, customers wanted input controls to be present
always and not depend on instance data. We have an "always" that
generates the insert actions.
John Boyer: So you want this to run on
reset or instance replace.
Nick van: Replacement is a bit
different; currently it's not done then because there you sometimes
get other data back. It's currently only on initialization.
John Boyer: That's good.
Leigh Klotz: It sounds like forced
structural validation.
Nick van: In our product, you can
define default values for controls. If the node isn't there we
initialize it with that value.
John Boyer: You need controls to exist
that bind to an empty node. If the user types into them then it
creates the node.
Leigh Klotz: If they don't interact
with the form does it insert the data?
Nick van: Yes.
Leigh Klotz: So it's a way of forcing
the instance to be structurally valid.
Steven Pemberton: It sounds like we
need to check with Erik. I thought we had already agreed. It sounds
like it exists because of user demand. If you can make certain
cases which happen easier it's good.
Leigh Klotz: Bind doesn't have enough
attributes to do this. It's missing context.
Steven Pemberton: That's what my mail
is about.
John Boyer: It sounds like this might
be a request for an initial value on a control. It could set it
up.
Nick van: And on repeat, specify a
number or maybe add only one more?
John Boyer: If it binds to zero nodes,
then the number attribute might control it. The
headache then is where is the origin.
John Boyer: Do you want to insert
whole subtrees, not just attributes and element leaf values?
Nick van: It would be nice to have
subtrees, if not just repeated structure.
Leigh Klotz: I'm worried we're getting
close to XSLT with arbitrary transformations. For attribute or
simple content element, maybe you can do the simple cases with a
simple mechanism such as a value child element under input and have
it also have the extra attribute. But if you add repeating
structure and then complex content, it sounds like a template
language. Maybe the answer is that you can't do it with
XForms+XPath, but with XForms+XSLT or XForms+XQuery.
Nick van: ...
Steven Pemberton: I think we need a
brief description of what implementations actually do from Erik and
Nick.
Nick van: We are using the insert
actions already in XForms, with if.
Steven Pemberton: Not from the
author's point of view. What does the author do?
Nick van: OK.
Leigh Klotz: Having a declarative way
would be great but I share John's concern that declarative might be
too hard to handle all the use cases.
ACTION-1854 Nick van den Bleeken to describe initialization value use cases and ask Erik Bruchez to do the same.