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]
Steven Pemberton: I think this
issue is solved.
Nick van: Yes.
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.
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>
<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">
foo(XForms.var.p);
</script>
</function>
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"/> </function>
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
<function> let $a := 42 (a, b) </function>
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">
foo(XForms.var.p);
</script>
</function>
<function name="my:foo(p as nodeset)" as="number" override="no">
<sequence select="sum($p)"/>
</function>
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.