Erik Bruchez, Inventive Designers/Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI (chair)
Steven Pemberton: The call is an hour earlier for Europe next week and the week after.
Steven Pemberton: I let Philippe Le Hégaret know.
Steven Pemberton: We did that last week.
Erik Bruchez: A exchanged a few
tweets with Joern Turner from betterForm on using more attributes.
He was entirely supportive of reducing markup in XForms.
Steven Pemberton: That's good news. I
have an action item which I have not yet completed.
Steven Pemberton: Let's not continue his right now.
Nick van: This is from our
Amsterdam editorial meeting. We need to come to a conclusion on how
we could do it.
Steven Pemberton: Why can't we just
use XSLT 2.0?
Nick van: It's modelled on how they do
it but we don't support all the constructs.
Steven Pemberton: Oh, I see not XPath
2. So it's a subset of XSLT 2 that matches what we do supply in
XForms.
Nick van: In XSLT 2 you can return a
mix of text and nodes.
Steven Pemberton: What would you like
to discuss about it?
Nick van: The examples in the wiki
page.
Leigh Klotz: I'd also like to take a
look at doing this with JavaScript functions as well.
John Boyer: Yes, I'd like to be able
to guarantee that the extensions work across all processors. For
example, for the sumproduct function, I'd like it to work
regardless of the processor. I think this is the most remarkably
inefficient way to do this for production in practical scenarios.
Maybe just a way of saying "we've got the functions"
Nick van: Why do you think JavaScript
will be faster than XPath? You'll have to switch to the JavaScript
and get the data model. That may have more overhead.
Erik Bruchez: I don't think that in
theory there would be a big difference; you can optimize a sequence
of variables and functions in XPath to be as fast. An existing
JavaScript interpreter such as V8 or Rhino...just using DOM and
jQuery might be fast. So I wouldn't know which would be fast. The
reality is that we don't have a powerful-enough general purpose
language in XForms. If we had XQuery instead of XPath that would be
better. If you use XQuery that would be better. Or JavaScript would
be the way to go. The question is what we would specify. So as a
baseline we could have functions that are a simple one, then what
else?
John Boyer: Looking specifically at
the sumproduct function, if you look at it, the way we implement
this is by running [1] predicates for the first element, and then
recursively calling the product function, because we have no loop.
We'd run into real performance problems. How many features do we
have to add before we have production ready custom?
Nick van: In XPath 2.0 you have a for
loop.
Erik Bruchez: In XPath 1.0 you have to
retrifit it.
Steven Pemberton: XPath 3 has fold as
well.
Erik Bruchez: And XPath 3 has
anonymous functions. Named functions maybe, or perhaps only in
XQuery. They are first-class objects. If we had XPath 3 available,
the picture would be available. Or XQuery, which is really a
full-fledged programming language with functions and modules; it's
on the same level as JavaScript but tailored for the XML data
model. Other than that it's a reasonable language; it even has map.
There's talk about set and other general-purpose data structures. I
agree that it's hard in XPath 1. It's difficult and not very
interesting to move XPath 1 to a general-purpose language.
John Boyer: Or even XPath 2. I don't
think we should have to consume something bigger than XForms to
make XForms work. It would be nice if something smaller
worked.
Erik Bruchez: XPath 2 isn't that big,
and XPath 3 is an increment on that and XQuery is an increment on
that. The optimizations and JIT would make JavaScript bigger than
XQuery.
Erik Bruchez: With variables, you
could put your functions in a variable in XPath 3 and then call the
functions from a variable. XPath 3.0 is a step too far for XForms
2.0.
Leigh Klotz: If these are declarations
with a baseline XPath 2.0 implementation, then perhaps we should
look at this as an import rather than a definition, and especially
with XPath 3 first-class functions in variables and XQuery modules
then maybe we should be looking at module import rather than a
single function import.
Steven Pemberton: For packaging
calculations up into a unit as an abstraction, it seems rather
userful, even if it's only a macro notation.
Nick van: sum(for $i in count($p)
return $p[$i]*$q[$i])
Erik Bruchez: As a baseline. If we say
it's something else then it's less interoperable.
Leigh Klotz: Alain has JavaScript
function calls but no type declarations. What would it take to
define a function that's callable as a JavaScript function.
Steven Pemberton: Mostly XFOrms works
without the strings though.
Leigh Klotz: For example, Math.cos
takes and returns numbers so you'd have to declare it.
Nick van: Integer is useful as well
for index.
John Boyer: You can't guarantee that
it's side-effect free if it's in JavaScript. But the efficient
looping in XPath 2.0 is there and it has the machinery to get the
job done. So we have at least one way that everybody supports. If
people want to add extensions for JavaScript, that's great, but we
don't have to support that uniformly.
Leigh Klotz: I don't think we should
require JavaScript but I think the syntax for it should be clear so
those who do write JavaScript functions can do it the same way.
type="text/javascript"?
Erik Bruchez: We already have the
ability to run JavaScript in actions in our product; we need a good
JavaScript API for the function. Nick:
<function name="my:foo" as="number">
<param name="p" as="number"/>
<param name="q" as="number"/>
<script type="javascript">foo($q, $p);</script>
</function>
Erik Bruchez: I could imagine a
type attribute on function. We already have the parameter
types.
Leigh Klotz: I would see them as the
same definition, but multiple implementations.
Steven Pemberton: <bind ref="p" type="integer"/> Nick:
<function name="my:foo" as="number"> <param name="p" as="number"/> <param name="q" as="number"/> <script type="text/javascript">foo(q, p);</script> </function>
Leigh Klotz: So then what if
JavaScript is not available? Could we have the XPath version?
Leigh Klotz: Like this?
<function name="my:foo" as="number"> <param name="p" as="number"/> <param name="q" as="number"/> <script type="text/javascript">foo(q, p);</script> <sequence select="choose(count($p) = 0, 0, $p[1] * $q[1] + my:sumproduct($p[position() > 1], $q[position() > 1]))"/> </function>
John Boyer: Could be.
Leigh Klotz: text/javascript
John Boyer: If there's no function
foo() but you have JavaScript then you'd get an error.
Leigh Klotz: So we'd try them in
document order?
Nick van: The first supported. We can
support variable declarations. We say the last element must be a
script or a sequence or both.
John Boyer: The script element might
also define and call foo.
Leigh Klotz: Right, we should be hands
off at that point.
John Boyer: Right, you call the first
one that you handle and if it works, it works.
Leigh Klotz: I'm happy with
this.
John Boyer: Me too.
Steven Pemberton: Is that a yes?
Leigh Klotz: I'm happy with
this.
John Boyer: I really like it because
people can write in JavaScript or XPath 2.0. Steven: <function
name="my:foo" as="number">
Steven Pemberton: This is more XForms-like.
Nick van: It's a bit more verbose.
We should use @as in our var element. Or maybe we should use @type
instead of @as.
Steven Pemberton: There's clearly some
relationship between subforms and functions; this would allow us to
use the dependency algorithm for calculations if we made functions
a subform with an instance as the parameters and a result value. At
least I could see that fitting into the dependency algorithm and
that could possibly make it faster because it only recalculates
bits that change.
Leigh Klotz: Macros?
Steven Pemberton: It could be a
function call, but only the changed parts need to be
re-evaluated.
Nick van: You'd have to create an
XForms instance or change one on each invocation.
Leigh Klotz: Create, because it could
be recursive.
Steven Pemberton: That's true of
functions anyway.
Steven Pemberton: What are the next
steps?
Leigh Klotz: If you keep it as XPath
definition then you can statically analyze it.
Nick van: Yes, Erik proposed that
initially.
Leigh Klotz: There's a chance an
implementation could do static analysis with XPath. With
JavaScript, it's unlikely to be statically analyzed though Michael
Kay may write a paper on it someday. With JavaScript, it's doable
right now for lots of implementations and it has blog appeal.
Steven Pemberton: OK, so we'll do that.
Resolution 2012-03-7.1: In http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions We add script/@type as an optional peer to sequence, which is also optional. The first recognized one in document order is used.
ACTION-1874 Nick Van Den Bleeken to implement to above proposal for custom functions in wiki
Nick van: Are we interested in
adding this? We should allow @ref in addition to @value because
@value is a string-value, not a nodeset.
Leigh Klotz: What about @select?
Nick van: When this was written we
were considering using @select, but no longer. So it would be
@ref.
Leigh Klotz: I'm confused.
Nick van: Remove @select and replace
it @ref and possibly add @value. It adds the context element on
dispatch, with @name and @ref|@value.
Leigh Klotz: Why is the element called
context?
Nick van: It's event context
information:
http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_event.28.29_Function
What is the name of the XPath function?
Nick van: event()
Leigh Klotz: Why is it context?
Leigh Klotz: We have @context that's
totally different.
John Boyer: True
Erik Bruchez: We're running out of
names.
Steven Pemberton: We need better
names. Maybe using or including.
Erik Bruchez: In DOM3, http://www.w3.org/TR/DOM-Level-3-Events/#events-Event
there is no custom information but ther is also a custom event
interface here: http://www.w3.org/TR/DOM-Level-3-Events/#events-CustomEvent
Erik Bruchez: It's called "detail."
There is no "context" terminology as we have.
Erik Bruchez: It's event.detail and
it's type any, readonly.
Leigh Klotz: That is the whole detail.
This is just part of it.
Erik Bruchez: detail is a bag of
things.
Leigh Klotz: It looks great, but we
just have.
Nick van: What do you call it,
Erik?
Erik Bruchez: We call it context, like
the event-context information.
Steven Pemberton: Where did we get the
name context from in the event section?
Erik Bruchez: From XML Events.
http://www.w3.org/TR/2010/NOTE-xml-events2-20101216/
Nick van: "Access to context
information for each event"
John Boyer: We refer to them as
context properties.
Nick van: So we could call the element
context property.
Steven Pemberton: DOM Level 2 talks
about "context information."
Erik Bruchez: DOM 3 doesn't talk about
it.
Steven Pemberton: Is it REC?
Erik Bruchez: WD from last year.
Erik Bruchez: They do use "contextual
information" in custom events. Or detail.
Leigh Klotz: Property sounds good to
me.
Steven Pemberton: Yes the word context
is used elsewhere. And property as in MIP.
Steven Pemberton: Let's just noodle on
it for a while. We agree this is useful perhaps?
Steven Pemberton: Do we add it with a
new name?
Nick van: Property?
Leigh Klotz: We have @context so we
shouldn't use element context. We do have a property function for
getting the version.
John Boyer: Alternatively we could
pass in a single instance. We don't want an onerous syntax.
Steven Pemberton: What about DOM3
detail?
Nick van: There's only one detail and
we have multiple.
Steven Pemberton: Let's just use
property then. Any objections?
Erik Bruchez: Or xf:param
Nick van: It's the other way
around.
Erik Bruchez: In XSLT to call and to
receive variables you use xf:param.
Leigh Klotz: And types?
Erik Bruchez: You could.
Erik Bruchez: Steven you pass in param
with the template.
Resolution 2012-03-7.2: We accept http://www.w3.org/MarkUp/Forms/wiki/Custom_event_context_information and rename xf:context to either xf:property or xf:param and @select to @ref and possibly @value.
ACTION-1875 Nick van den Bleeken to edit http://www.w3.org/MarkUp/Forms/wiki/Custom_event_context_information and rename xf:context to either xf:property or xf:param and @select to @ref and possibly @value.