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]
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.
Leigh Klotz: Alain is doing load/@show=embed. Take a look in XSLTForms SVN tree.
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.
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: 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.