W3C Forms teleconference December 7, 2011

* Present

Alain Couthures, AgenceXML
Leigh Klotz, Xerox (chair)
Nick van den Bleeken, Inventive Designers
Philip Fennel, MarkLogic
John Boyer, IBM
Erik Bruchez, Inventive Designers [joined late]

* Agenda


* Variables in XForms

http://lists.w3.org/Archives/Public/public-forms/2011Dec/0017.html http://www.w3.org/MarkUp/Forms/wiki/Variables_in_XPath#Proposal_.282011-12.29

Nick van: Variables are really handy. I use it a lot in Orbeon. This proposal adds variables in places where there is no ... or where Erik and I were not clear about scoping rules. In models, they are available from that point on and siblings. In actions they are available in the model and are updated when the action is updated. Not in an action updated on refresh. Also automatic bind variables, as we need more decisions there. So first variables in limited spaces first, if they group thinks so, then model, and then automatically-created variables for bind or perhaps a different attribute on bind. The binds are logical structure.
Leigh Klotz: I often thought XForms would have been easier if we'd named instance variable.
John Boyer: That would have made this feature harder.
Leigh Klotz: Just a different type.

John Boyer: One question: where we use value it is usually a string.
Nick van: In the text we always say that we convert it to a string. It's not @ref, because that implies a binding.
John Boyer: Then, do you intend that this is creating a name=string mechanism?
Nick van: No, an arbitrary sequence of items, or an atomic value.
John Boyer: In this case, @value doesn't what it does elsewhere. Is that a different name?
Nick van: Erik first suggested @select but Steven was a bit... First we had @nodeset and @ref, now we only have @ref.
John Boyer: @ref would be a bad name. The expectation is a set of nodes or a node, maybe bigger in XPath 2.0. @select actually sounded a bit better to me, anyway.
Nick van: If we do repeat/@ref then what do we do with a sequence of items? Why do we ever need something else other than @select on repeat?
John Boyer: I hear you. But @value is so heavily burdened in XForms with stringness.

John Boyer: The other question: what is the evaluation context or @value.
Nick van: Where it is positioned, the in-scope evaluation context.
John Boyer: So if the var appears inside an iterate, or a repeat, how do we deal with there being only one name?
Nick van: The same id resolution.
John Boyer: So the variable name is only accessible within the repeat?
Nick van: Yes, variable scope is visible for all following siblings and their descendents. So you can't go outside the repeat.
John Boyer: In the runtime sense, but not source-document sense, for following siblings.
Nick van: Yes. When you have multiple iterations and unroll the XML, every iteration will create a new parent element so they won't interact.
John Boyer: How about iterate inside action?
Nick van: It's the same. We need to add some wording for that. It should be the same as if the parent of the iterate is repeated; it is in the current iteration only.
John Boyer: If you're within the same context, what if one of the following siblings has the same name? Does that override or replace?
Nick van: "It is an error to create multiple bindings with the same name if they are visible to each other."
Leigh Klotz: So consider repeat/var and input and output of the var. If I change the node via input, the output presentation changes on refresh?
Nick van: Yes
Leigh Klotz: So it's like bind/@calculate?
Nick van: They act as if they were updated in documented order.
Leigh Klotz: What if there are dependencies?
Nick van: You can't refer forward so doing evaluation in document order is OK.
Leigh Klotz: The value of variables changes on refresh?
Nick van: If in an action, when the action runs. If oustide action, only on refresh. We don't allow variables in the model outside actions, so we don't have to create rules for use with @calculate. So it's only in the UI.
John Boyer: You said something interesting; it's excluded from the model, except for in an action in the model. That's good because we create action sequences with custom event names.
Nick van: It's my experience with variables that this covers most cases.
Leigh Klotz: Why is it refresh and no recalculate? I'm worried that that is too late, for example for predicates.
Nick van: That's on refresh. Maybe I'm wrong but I think that everything in the UI behaves as if it's calculated on refresh. It's only in the model where things happen during recalculate.
John Boyer: I agree; the model is the first implicit step of refresh is a UI rewiring. I agree that this happens during that.
Leigh Klotz: If you're not concerned I'm fine.
John Boyer: I'm worried more about wiring during action sequence but that's a separate issue. It makes a lot of sense to me to happen during rewiring.
Leigh Klotz: OK
John Boyer: During a run of an action sequence, we tend to mutate data. If a var runs as step 1 of an action, and the @value is evaluated and it's got predicates, the variable takes a value at that moment in time. If step 2 does a setvalue, it sounds like the variable doesn't change value even though it would be dependent on the setvalue, as it's evaluated at a moment in time.
Nick van: Good point. I use variables a lot but I never came to that consequence.
John Boyer: Is that the way it works? The variable doesn't subsequently change?
Nick van: That's how it's implemented in Orbeon.
John Boyer: That sounds consistent with XSLT.
Nick van: You can't modify data in XSLT.
John Boyer: True.
Nick van: You can in XQuery but they are applied after you're done. In our case, using Orbeon, they are pointers to the instance so if you delete a child, it is reflected. Otherwise you cannot use them for an insert, if they are clones.
John Boyer: So when we do a variable, it takes on a value, but a subsequent delete will update?
Nick van: It's a variable like in Java. It's a pointer to that node. If that node changes, the variable stays the same but the content isn't immutable.
John Boyer: There's a difference between a variable bound to the node and I change the node, where I would expect the string value of that variable would be different, but it still binds to the same node. If you change something that affects a predicate in the value expression so that it would, if re-evaluated, bind to a different node?
Nick van: In Orbeon, I think you select the sequence once when you process the variable and it won't affect it. Maybe that isn't what we want. If we really want to make it live then....
Leigh Klotz: It turns into calculate, then.
John Boyer: does the node bound to x change?
Nick van: Calculate only calculates at recalculate. But even those if you change the predicate you have to do a refresh. So it may fall into the category of things that sometimes don't work so great in XForms.

John Boyer: step one var name="x" value="some/node[pred]"
John Boyer: step two do a setvalue that changes pred
John Boyer: step three delete some/node[pred]
John Boyer: does the node bound to x change?
Nick van: In my opinion it will still point to that node, but it won't be in the instance.
Leigh Klotz: I think that issue is separate and however we decide it won't affect this feature.
John Boyer: I think it's fine to have the variable still point to the deleted item.
Nick van: Yes, then you can insert it elsewhere.
John Boyer: From a lifecycle perspective the processor gets rid of the variable data when it's no longer in scope.
Nick van: ...
John Boyer: That makes sense, but it seems odd so we need some additional words that say that if you evaluate a variable, there's no subsequent changes or dependencies.
Leigh Klotz: So that would be a note?

ACTION-1847 - Nick van den Bleeken to add note to Variables about one-time evaluation.

John Boyer: And we leave out the variables inside the model to avoid complexity. It avoids complexity. It seems like we could make it work but it's a lot of work.
Nick van: I was going to write it up but I hit a lot of corner cases.

Nick van: I use it a lot to make the form more readable, to break up complicated expressions.

* load/@show=embed

Leigh Klotz: Alain is doing load/@show=embed. Take a look in XSLTForms SVN tree.

* giant cookies / HTML5 local storage


Leigh Klotz: Much of XForms and HTML5 interaction is DOM or Event driven and just works. I knocked out a prototype of this in XSLTForms using local://name. It would be good to produce a URI scheme for it, and for session storage, etc. Then we'd have no spec-work in XForms.

* Custom XPath functions in XForms


John Boyer: This seems like one of the most important extension mechanisms we could put in.
Leigh Klotz: I thought this proposal so far was only about implementing XPath in other XPath.
Nick van: It does mean you can recognize pattern idioms and provide faster versions.
John Boyer: Yes, recognize a pattern and replace it. Or the function syntax might refer to implementation code.
Leigh Klotz: I'd like to see a requirement for XPath as the implementation language but allow processors to have implementations declare others such as JavaScript.
Nick van: As long as we make sure they are side-effect free, as it would be a mess.
Leigh Klotz: In JavaScript, people can do side effects and we can't prevent it but we can make it clear it's the mess they've made.
Philip Fennel: We could allow declaration of import of XSLT and XQuery functions, which are side-effect free.
John Boyer: The function has to come from somewhere. It's nice that the wikitext says that you can write it directly in machinery we already have, so that's an option.
Erik Bruchez: [joins]
John Boyer: You might have to re-express certain functions, but you'd at least know.
Philip Fennel: You might as well use the XSLT prefix for it.
Leigh Klotz: You mean the example?
John Boyer: The example?
Nick van: In our proposal we allow it explicitly only with a sequence element.

Nick van: Leigh's proposal was also to allow it to be implemented in other languages, for example JavaScript. Also XSLT function libraries.
Leigh Klotz: So function, param, variable, etc would be the same but the last part would be different?
Nick van: Why should the author create the signature for another time?
Leigh Klotz: Having a standard would be better than what XSLTFOrms currently dones.

Nick van: You have to keep it in sync the other language.
Leigh Klotz: There is no function signature, it's declarative.
Nick van: It's repeated. I'd say you could include function libraries from a separate resource.
Leigh Klotz: How do they declare their functions?

Nick van: Some people have ways of doing it in XSLT, and it makes sense to have both ways.
Leigh Klotz: I think it's a common case on the web and I don't see a reason for doing it in two places.

<script type="text/javascript"> function(num) { return num * num; } </script>

Nick van: You have done it twice. What if it's in Java.
John Boyer: It would be nice to have a way to declare the extensions and see everybody using it and have alternate implementations, perhaps in JavaScript or Java or C++. For each implementation there should be some other place. The function still has to exist.
Leigh Klotz: I think Javascript is an important use case and even Orbeon can run Rhino.
John Boyer: We allow people to create Java classes and embed them in the form. With an extension mechanism we could have extension XPath functions, with an xf: function with an implementation in this select sequence language, as the baseline implementation, and if an alternative exists, C++ or Java that might be used instead.
Leigh Klotz: Right. What's the extension signature for doing it if it's not script/@type. For Java classes, for example.
John Boyer: Yes, an internal implementation might want to list it as well.
Leigh Klotz: Not even something like jarpath="com.mumble."
Philip Fennel: Saxon provides this: <xsl:value-of select="math:sqrt($arg)" xmlns:math="java:java.lang.Math"/>
Philip Fennel: "This will invoke the static method java.lang.Math.sqrt(), applying it to the value of the variable $arg, and copying the value of the square root of $arg to the result tree." though I've never used it.

Nick van: In this example you don't have to provide argument types.
Leigh Klotz: Even in Saxon there is another extension mechanism where you do, as this works for only simple things.

Leigh Klotz: OK, this is blue-sky future and we need to go as we're over time.

* IRC Minutes


* Meeting Ends