W3C Forms teleconference March 14, 2012

* Present

Alain Couthures, AgenceXML
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI (chair)
Erik Bruchez, Inventive Designers [late]

* Agenda


* Missing wikispec sections restored

http://lists.w3.org/Archives/Public/public-forms/2012Mar/0006.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0010.html

Steven Pemberton: I think this issue is solved.
Nick van: Yes.

* Community Group and Isotype

http://lists.w3.org/Archives/Public/www-forms/2012Mar/0001.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0012.html

Steven Pemberton: You ought to create a place where it can belong.
Nick van: If there are only a few people it may give a bad signal.
Steven Pemberton: We do need to be rechartered or extended.
Steven Pemberton: Who would join?
Leigh Klotz: I would join, and it seems like betterForm might and Isotype.
Steven Pemberton: Yes, non-member implementors could join.
Nick van: And if we had XForms users and two or three other people it might not send a good signal.
Leigh Klotz: Isn't there some type of agreement for contribution to join, vs www-forms?
Nick van: You can't produce a spec but you can investigate and discuss. But you can create a note.
Steven Pemberton: You can do prep work, but the IPR policies include a contributor agreement.
Nick van: When joining the WG you have to declare patents, but not in a community group.
Leigh Klotz: It says http://www.w3.org/community/about/agreements/cla/ says "I agree to license my Essential Claims under the W3C CLA RF Licensing Requirements."
Leigh Klotz: Joern said that "you can join by personal endorsement" in the www-forms list, but I think we need something a little more than that.
Steven Pemberton: You have to have a proposal and 4 people to support it.
Leigh Klotz: This sounds like a replacement for www-forms with IPR protection.
Steven Pemberton: It may give a sense of belonging but it requires a IPR.
Nick van: I believe EMC is participating in pipeline.
Steven Pemberton: Assuming we go ahead, what is the aim?
Leigh Klotz: One possibilit is to give a voice for XForms users.
Steven Pemberton: That might be a useful focus. Shall we try it as an experiment?
Leigh Klotz: I think so.
Alain Couthures: Me too.
Steven Pemberton: Anyone else endorse it?
Philip Fennell: Yes.
Leigh Klotz: I would participate and it sounds like Joern and possible Haakon might.
Steven Pemberton: So we call it the XForms Users Community Group?
Leigh Klotz: Sounds good to me.
Steven Pemberton: To dicuss the use of XForms and propose changes or additions to the language.
Steven Pemberton: http://www.w3.org/community/groups/proposed/#xformsusers
Leigh Klotz: I voted for it.
Nick van: After you log in as AC rep?
Steven Pemberton: No, as member.

Steven Pemberton: So what about Isotype?
Leigh Klotz: We ask Isotype to join this group.

* Custom XPath functions in XForms

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0021.html Updated with spec changes http://lists.w3.org/Archives/Public/public-forms/2012Mar/0005.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0007.html http://lists.w3.org/Archives/Public/public-forms/2012Mar/0011.html

Nick van: Alex and I had a discussion here: https://gist.github.com/2002642
Nick van: The initial context is empty. I am biased toward not allowing "." in Xpath function body.
Leigh Klotz: I see at least three issues: are variables lexically scoped, is context available, and what is the syntax.
Nick van: I think we should allow variables as in XPath 3.0. I think the initial context should be empty, as in XPath 3.0: that makes sense because it makes the function depend on where it is defined. XSLT also has the context empty.
Nick van: I gave an example of how that works.

<var name="context" value="."/>
<var name="context-pos" value="position()"/>
<var name="context-size" value="last()"/>
<function signature="my:f() as number" value="$context-pos = $context-size"/>
The variables in scope for the function body include all variables representing the function parameters, as well as all variables that are in scope for the inline function expression. Note: Function parameter names can mask variables that would otherwise be in scope for the function body.

Leigh Klotz: Aren't they defined where the variable is defined and immutable? If I defined the function in the head, wouldn't context-size and context-pos be meaningless?
Nick van: Alex said you could define your function anywhere and use it anywhere.
Erik Bruchez: [joins]
Leigh Klotz: If you need context it seems like you should be able to pass it in.
Nick van: In XSLT2 you could only access global variables or parameters, not variables in scope at definition. In XPath 3.0 they opened it a bit and added in-scope.
Leigh Klotz: How is this example useful?
Nick van: If you use it in a repeat?
Leigh Klotz: How is this different from just adding a 4th variable?
Nick van: If it took more parameters it would be different.
Leigh Klotz: So it isn't a good example for the use case, and you can't write a function in a library that uses variables to get context.
Nick van: Right. I want to go the XPath 3 way and not initialize the focus.
Leigh Klotz: It seems clear you cannot have the context since XPath 3 does not.
Erik Bruchez: Mike Kay confirms you cannot have a context item.
Nick van: https://gist.github.com/2002642
Erik Bruchez: Yes. I believe you should have the lexical context if you have lexical variables. It seems weird to me, but we should stay compatible.
Nick van: It may be hard if we don't go the XPath 3 direction.
Erik Bruchez: It's a shame; I don't know why they decided this.
Leigh Klotz: OK, so lexically defined variables and no context.
Nick van: Yes.
Leigh Klotz: And Erik and Nick, you agree that's what XPath 3 does?
Nick van: Yes, that's what Michael Kay says.
Leigh Klotz: Adding context or using dynamic variables would be incompatible.
Nick van: "
Steven Pemberton: Does anyone object?

Resolution 2012-03-14.1: Custom-defined functions get no context item, position, or size, they have access to lexically scoped variables.

Leigh Klotz: Now the syntax issue.
Nick van: Here is the original proposal:

<function name="my:foo" as="number">
   <param name="p" as="number"/>
   <param name="q" as="number"/>
   <sequence select="$p + $q"/>

<function signature="my:f(p as number, q as number) as number" select="$p+$q"/>

Steven Pemberton: Do we allow both syntaxes?
Leigh Klotz: My concern is that you run out of quotes.
Steven Pemberton: Oh yes.
Leigh Klotz: Is function @signature and @value taken from XPath 3?
Nick van: No, they are inline.
Leigh Klotz: Why not just <function> ... whatever xpath 3 says </>
Erik Bruchez: The idea is to separate the implementation from the declaration.
Leigh Klotz: I can see how that works in the long version, but not the short version.
Erik Bruchez: It works the same in the short version.
Leigh Klotz: What about JavaScript? Do you put that in an attribute?

Nick van: Like this:

<function name="my:foo(p as string)" as="number">
   <script type="text/javascript">

Erik Bruchez: We can use the XPath function signature declaration; that's the main thing. If you have a simple XPath expression, putting it in an attribute is a great thing. Or the body.
Leigh Klotz: So there are two parts: always use the XPath declaration signature, and for the body, either use @select for XPath or a body that can contain either XPath (in sequence or JavaScript in script). Maybe a better name than sequence.
Nick van: Sometimes you want a set of sequence elements.
Nick van: <function signature="my:f(name as string) as string" type="javascript" value="foo(XForms.var.p)"/>
Leigh Klotz: I don't want to do anything that requires JavaScript in attributes.
Erik Bruchez: It should be allowed.
Philip Fennell: You may want to use CDATA in your function declaration, for inlining.
Nick van: sequence with @value

<function signature="my:sumproduct(p as number)" as="number*">
  <sequence value="2*$p"/>
 <sequence value="3*$p"/>

Leigh Klotz: That works for me.
Erik Bruchez: When I asked Mike Kay about custom functions, he said we didn't need the sequence constructor. But we need a way to express a returned value that is not a string value, that consists of a sequence of items.
Steven Pemberton: Do you have enough input to carry on?
Nick van: If the group thinks so.
Leigh Klotz: It sounds like Erik still has some concerns about the long version with sequence.
Erik Bruchez: I think it depends. There was an idea to allow more nested elements within the function. A function would include two things: variables and the result. If we keep around variables then that means the function body is expressed in XPath as a series of nested elements. Then we need an element such as sequence to express the result. So we still plan to have a variable element?
Nick van: Yes, it's in the spec now.
Erik Bruchez: Unless we support XPath 3 only, XPath 3 has variables, so the body could just be XPath. We wouldn't need nested elements

let $a := 42
(a, b)

Nick van: If you had XPath 3 then you could write it completely in a string as the attribute of the function.
Erik Bruchez: However, from a clarity perspective, being in the body of the element as the text body would make it nicer, just like JavaScript. If you want to have variables and an expressions...I realize my idea is not fully formed. Let me write email.

ACTION-1876 Erik Bruchez to propose forward-compatible function body syntax for XPath 3.

Steven Pemberton: So we should wait on that, Nick.

Nick van: Do we agree to have a mix of scripts and sequence elements as alternate implementations? I proposed @override=no:

<function signature="my:foo(p as nodeset)" as="number" override="no">
   <script type="text/javascript">
<function name="my:foo(p as nodeset)" as="number" override="no">
   <sequence select="sum($p)"/>

Nick van: Then you can provide a JavaScript version of a native function.
Leigh Klotz: It sounds reasonable but we're out of time.
Nick van: Can I edit the XPath 2.0 document?
Steven Pemberton: Sure. We can always change it.
Nick van: Oh, I also added a script action
Nick van: I hope the group isn't against this one.

* IRC Minutes


* Meeting Ends