W3C Forms teleconference March 7, 2012

* Present

Erik Bruchez, Inventive Designers/Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI (chair)

* Agenda


* Administration

Steven Pemberton: The call is an hour earlier for Europe next week and the week after.

* First Public Working Draft

Steven Pemberton: I let Philippe Le Hégaret know.

* Made basic event properties available for the event() function


Steven Pemberton: We did that last week.

* More Attributes

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.

* Expand data model of ref to an arbitrary sequence


Steven Pemberton: Let's not continue his right now.

* Custom XPath functions in XForms

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0021.html http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions

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>

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>

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]))"/>

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

* Custom event context

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0006.html http://www.w3.org/MarkUp/Forms/wiki/Custom_event_context_information

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.

* IRC Minutes


* Meeting Ends