Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Uli Lissé, Dreamlabs
Keith Wells, IBM
Blake Jones, DAISY/ViewPlus
Sebastian Schnitzenbaumer, Dreamlabs
John Boyer: Our next telecon is January 9, 2008. It starts 15 minutes earlier and runs 15 minutes later in your time zone.
Mark Birbeck: I'll try to get to this before we break for the year.
John Boyer: Thanks to Erik, Uli,
and Nick for holding the email discussion. Nick pointed out that we
might need to define custom functions.
Erik Bruchez: Both XQuery and XSLT 2.0
support it; even custom functions in XSLT. The idea is that you use
the constructs to define a function you can use any place you have
XPath expressions (style sheet, model). We might be less tempted to
add functions all over the place; you can achieve re-use by writing
your own function. XSLT and XQuery are quite complete languages and
XForms is not, so I'm not sure of the details. The simplest thing
would be a way to assign a function as another XPath
expression.
John Boyer: I like the extension
idea. Or a way of wrapping XForms actions, and not have them mutate
objects other than in the functions. Then you can use @if and
@while.
Erik Bruchez: I think that would be
good to be able to use actions. Not being able to re-use sequences
of actions with parameters is a problem; you can re-use actions by
dispatching to the model, but without parameters or return values.
You have to use hack instances and it's awkward.
John Boyer: The xforms:function
concept could easily use xforms:param or something els like XSLT
templates. We'll get pushback if we don't make a limitation that
the function can't have side effects. So we could limit it to the
instance inside the function.
Erik Bruchez: In XPath you want them
side-effect free as well. But imagine a function that returns void
(empty sequence, empty nodeset) which does actions. If there were a
way, it would cover some use cases, but I'm not sure how. But
extension functions can have side effects. At the low level of the
implementation, XPath allows side effects.
John Boyer: So there is a way to
signify that there are side effects? That runs roughshod over our
ability to track dependencies.
Erik Bruchez: I don't know if it's in
the spec.
John Boyer: We got into trouble with
Michael Kay over XPath before with the random and now functions.
Modifying the instance is even more egregious.
Erik Bruchez: With XQuery and XSLT 2.0
it's all XPath 2.0; Michael Kay says they don't really
differentiate between XSLT 2.0 elements and XPath functions. ...
and the value is an XPath expression. So you could get
pushback.
John Boyer: It reminds me that we need
to tell the difference between side effects or not. That reminds of
of Pascal procedures vs. functions. We could have functions being
side-effect free and procedures a reusable set of actions, and get
around the parameter problem. Anybody else have opinions?
Leigh Klotz: I think we should focus
on the interface and not the implementation and consider this part
of the interface to XForms, and then towards being able to add
libraries of custom libraries.
John Boyer: I think that is a separate
feature; if you want to be able to write something that works
everywhere, we have a way to do that.
Leigh Klotz: I think they're two
separate problems and we should try to think of them separately and
make sure it meets in the middle. There are three things: how and
what we add (and we have identified two nascent points: XPath
functions and actions), how they are specified (the inflection
point) and then how to implement them, and on that last one, wholly
self-contained implementations may be possible for many, but we
should also allow native or external implementations (JavaScript or
internal) which will encourage the development of function
libraries as it has for XSLT.
John Boyer: Nick, anything to
add.
Nick van: [irc] I'm agreeing with
it
John Boyer: Should we do this for
XForms 1.2?
Nick van: [irc] but what we do then
with sumproduct?
Mark Birbeck: I'm agreeing too. The
sooner we start addressing reusability the better.
John Boyer: It's not easing
on-the-glass but it does ease authoring.
Nick van: It's my feeling too. If we
don't add it in 1.2 then we still have the problem with sumproduct
in 1.2. That's the main reason I proposed the ability to define
functions.
John Boyer: It shoots the necessity of
adding sumproduct, decimalstring, and others we haven't come
across. It addresses reusability and Erik's way of having an easier
way to invoke things.
Nick van: We can add a list of them in
an appendix just like XSLT has.
John Boyer: Yes, as Leigh says, a
native implementation can be faster and an implementation could
decide to use it.
Leigh Klotz: I'm hearing namespaces
there. It's just like in XSLT and exforms.org.
John Boyer: I think we have a proposed
resolution to work on this for XForms 1.2.
John Boyer: Proposed Resolution: Add
to XForms 1.2 the capability to express function and procedure
interfaces and implementations.
Leigh Klotz: Are actions and xpath
the only two points we plug things in?
John Boyer: Those are the only two
things with regard to side effects; either have them or they
aren't.
Leigh Klotz: Are xpath expressions
(model and ui) and actions the only two places? What about
presentation controls as in XBL? Or are we far enough away from
presentation by being abstract.
John Boyer: So the eventing paradigm
might be one, the event handlers.
Leigh Klotz: That's events again. I
just want to make sure there's enough places.
Mark Birbeck: In XML Events 2 we added
the ability to add have script inside action sequences. So, it
means that the distinction among action, script, and function
starts to blur. And secondly, I wonder if we can make use of it to
allow calling an action from an XPath expression.
Leigh Klotz: There's also validation;
Schematron plugs XPath into other Schema languages. We use XPath
for that already, but can we plug in new functions there? Or how
about serialization? I want to make sure that it's not just
xf:action/* and */[@nodeset or @ref or @value] that we can
use.
John Boyer: Can we get some
wording?
Leigh Klotz: "Add to XForms 1.2 the
capability to define interfaces to and implementations of
extensions for both side-effect and side-effect-free operations,
along with the specification of which points these extensions may
be invoked, including but not limited to XPath expressions and
actions."
John Boyer: Good. [irc] CharlieWiecha,
John_Boyer, ebruchez, Nick, wellsk, Blake, markbirbeck,
Schnitz.
John Boyer: So resolved.
Resolution 2007-12-19.1: Add to XForms 1.2 the capability to define interfaces to and implementations of extensions for both side-effect and side-effect-free operations, along with the specification of which points these extensions may be invoked, including but not limited to XPath expressions and actions.
John Boyer: Who wants to take the
action item to pull together some spec-ready text?
Erik Bruchez: We should come up with a
proposal for syntax first.
John Boyer: I agree. It'll take a
couple of iterations. You could write sumproduct or decimal string
as examples.
Erik Bruchez: I am not sure I can
commit to write the whole thing but I can get the ball rolling for
how to declare a procedure in the XForms model.
Nick van: [irc] sounds perfect for
me
John Boyer: Nick you want to do
it?
Nick van: No, Erik will do.
Leigh Klotz: I will go look for more
places to add it.
John Boyer: Sounds like two
actions.
John Boyer: Erik, can you own
this?
Action 2007-12-19.1: Erik Bruchez to send email to write up initial draft for extensions.
Action 2007-12-19.2: Erik Bruchez to produce spec-ready text for XForms 1.2 extensions.
Action 2007-12-19.3: Leigh Klotz to investigate and report on possible uses for extension functions outside of xf:action/* and */[@nodeset or @ref or @value].
Erik Bruchez: If we delay XPath 2.0
to XForms 2.0, then it may take years. If we add function libraries
it may be less important. However, we still need it. In the XProc
work we are doing with W3C, based on feedback from Michael Kay and
others, we decided to allow either 1.0 or 2.0 and specify in the
program whether the form author is requesting 1.0 or 2.0. There is
decision logic in the spec that gives maximum flexibility to
authors and implementors. I think we can do this before XForms 2.0.
Also, if we have a big spec, then it will take a long time to get
there. Our experience with XPath 2.0 shows you can integrate it in
a light-weight way with most of the benefits. So I think it would
be a good idea to try to specify XPath 2.0 support in modular way
on top of XForms 1.1 or 1.2.
Nick van: [irc] we maybe even want to
allow different languages for the query (to specify node sets and
refer nodes), constraint and calculation language
John Boyer: In the XML Signatures
recommendation they had different algorithms at different
requirement levels. For filtering, for example, there were "should"
and "may" and "must". So we may want to talk about an optional
XPath 2.0 binding.
Nick van: [irc] If we do add XPath 2.0
I would prefer we first try if we could add support for pluggable
languages
Erik Bruchez: It may give implementors
more confidence to move in this direction if we have something
earlier; otherwise, they will wait 5 years before looking at
it.
John Boyer: The scarey bit for me is
XPath 2.0 in an XPath 1.0 processor even though it specifies a 1.2
processor. So maybe there is a versioning capability and it
requires some pluggable module as Nicks says, not just functions,
but other equipment such as XPath 2.0.
Erik Bruchez: XPath is a fundamental
part of XForms so an attribute for that is fine for me. If you say
XPath 2.0 is mandatory for XForms 2.0, and you don't have XForms
2.0 then it won't work anyway.
John Boyer: Absolutely, but it could
be more generic: xpath-2.0, javascript, etc.
Mark Birbeck: [irc] But could also
support JSON, for example. Perhaps my @hasFeature proposal from
years ago?
Erik Bruchez: Can we quickly do this
as a separate document under our charter?
John Boyer: We can double check with
Steven, but my prior experience is that we can produce other
documents in addition to the requirements.
Nick van: Or a note.
John Boyer: It would be nice to have
the content first. The XML Signature WG produced a plethora of
products: XML Canonicalization, Exclusive Canonicalization, and
XPath Filter 2, which bears some relationship to our issue, of
using another technology with our existing recommendation
track.
Leigh Klotz: I like XPath 2.0 and
Erik's proposal sounds like a good way to get people to look at it
early.
John Boyer: No resolution, but an
action to look at the module. I'm not sure we can backport it to
1.1 because of the Schema change for @hasFeature or whatever.
Erik:
Action 2007-12-19.4: Erik Bruchez to investigate adding XPath 2.0 to XForms 1.2 in a modular way that encompasses adding other pluggable languages in the future.
John Boyer: OK, see you all in the new year.