Alain Couthures, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI (chair)
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon [joined late]
Steven Pemberton: At the ODF Meetup I added the Easter Date Calculator in Open Office. Some implementations worked and some didn't. I noticed they don't have output so I will propose adding that to ODF 1.3. http://homepages.cwi.nl/~steven/forms/odf-easter.odt
John Boyer: The hope was to add
@context to insert/delete in XForms 1.1 and then expand it
everywhere in the next version, where it overrides the in-scope
evaluation context node for an elements. There is a starting node
for input/@ref inherited from the element context. If the input is
not contained by group or repeat, it is the root element of the
default instance, but the context is changed inside group or
repeat. The context attribute would be evaluated in the initial
context and then its result overrides the element's ref or other
references.
John Boyer: When applied to an XForms
insert, it does have that behavior, but it also describes the
parent element of the nodeset you are inserting to. You express a
nodeset binding and the @at selections a position, and @position
sets before or after. The problem we hit with XForms 1.1 is the
empty nodeset: you need a parent element to start things off. We
didn't add a separate @parent and re-used @context and said it was
used only if explicit. It was a hack that worked OK at the time but
causes us grief now. So if you use insert/@context it not only
overrides the starting context of the nodeset, it also specifies
the parent if @nodeset is empty. The overloading has been mostly
harmless, but it's causing us grief with @iterate.
Steven Pemberton: So you're suggesting
we add a @parent attribute, which if there, takes over the role of
parent from @context; if it's not there, @context behaves as
is.
John Boyer: Whether @context still
does that is a point of negotiation.
Steven Pemberton: It seems best for
backwards-compatibility.
John Boyer: We should at least have
the expressive power. With @iterate, you would use @parent instead
of @context.
Leigh Klotz: If the nodeset is
non-empty, does @parent do anything?
John Boyer: The nodeset could be
evaluated relative to @parent.
Leigh Klotz: How is that different
from @context?
John Boyer: It doesn't reset the
context of the insert itself. That changes what the context
function returns.
Leigh Klotz: So if you have @parent
then @nodeset is evaluated with respect to parent?
John Boyer: That is the reasonable
approach.
Leigh Klotz: And if you have @context
then @nodeset is evaluated with respect to context?
John Boyer: That's right. The problem
comes with @origin. We're trying to consume a context provided by
@iterate. See the first markup example. For each element I want to
insert into some parent element and the origin is whatever the
iteration node is. I acn't use . because the context
attribute resets the context. The insert will insert into some
parental element but the origin comes from the context which comes
from the @iterate. This isn't the only problem that's come up but
the workarounds this time are cleverer than they should be. For
example, to flip nodes I had to work on all elements except the
first. The hack is creating complexity now.
Steven Pemberton: You've argued it
coherently. It sounds like it works. The only thing we have to
watch out for is back ward compatibility.
Leigh Klotz: And whether it can be
explained to people who understood the previous thing.
John Boyer: @parent takes on the
secondary role of @context for insert, of providing the parent into
whose child space we want to insert.
Steven Pemberton: That's only of
interest if the nodeset is empty, right?
John Boyer: Empty or not specified. If
nodeset is omitted, it prepends as the first child. For example,
same as if the nodeset produced was empty due to do some
predicate.
Steven Pemberton: That's the same as
when it's empty. If the nodeset isn't empty, what do you do with
parent?
John Boyer: In that case, it provides
an overload of the initial evaluation context of the nodeset
itself. Typically you don't have the flexibility at runtime to
change whether the insert has a nodeset or parent attribute, though
I suppose you could use if. A table insert would have a parent and
a nodeset; when the nodeset becomes empty, it will insert an
initial element. When it isn't, the nodeset dominates.
Steven Pemberton: If you have the
nodeset you don't have to look at parent.
Leigh Klotz: If nodeset="x" then you
have to look at parent.
Steven Pemberton: I see.
John Boyer: We could say that nodeset
is evaluated relative to context. That might not be what we would
choose to do. I'd like the nodeset to be evaluated relative to what
we said the parent was. It's a point of discussion. In Nick's XPath
spec, we say nodeset and ref (anyway) behave relative to the new
context attribute. Now we're saying that the parent attribute for
insert will sit between context and nodeset or ref. That is a
specialized behavior.
John Boyer: We have to decide between
having a specialized behavior and the author readability and the
word parent,nodeset,ref.
Leigh Klotz: If it's not special to
insert then it looks funny. If it is special, then it's an
exception.
John Boyer: @parent is already an
attribute of insert only, but should it create a special
relationship between context and nodeset|ref.
Steven Pemberton: Personally I'd
prefer it if it didn't.
John Boyer: That makes it a little
weirder to read. Here's an example.
John Boyer: This is the special
behavior where parent overrides the eval context of nodeset:
John Boyer: <insert
parent="purchase/order" nodeset="row" ...
John Boyer: This is the non-special
version:
John Boyer: <insert
parent="purchase/order" nodeset="purchase/order/row"
...
John Boyer: This is what they're
likely to write:
John Boyer: <insert
context="purchase/order" parent="." nodeset="row"
John Boyer: People won't be able to
tell that nodeset is evaluated relative to context.
Leigh Klotz: What if I leave out
parent="."
John Boyer: It would work the same;
that's what works now.
Steven Pemberton: The problem works
when you add @iterate.
John Boyer: Then it's not the same use
case. That's not a table driver. You would use the @parent instead
of @context. That's where it gets weird that @nodeset is evaluated
relative to in-scope evaluation context rather than @parent. I'd
rather use @parent and don't need @nodeset at all. There's not a
huge amount of weirdness if we don't create a special behavior that
@context applies to @nodeset|@ref and @parent doesn't introduce
special behavior into that.
Nick van: John, in other cases in
XForms, the attributes are evaluated in the result of the previous
attribute: setvalue/@ref sets the context for @value.
John Boyer: Correct. It only sets the
evaluation context of the initial @ref or @nodeset.
Nick van: For @parent, @nodeset isn't
relative to @parent.
John Boyer: I argue that's what we
should do, that @parent provides special information but @nodeset
should not be evaluated relative to @parent.
Nick van: So @parent is weird if it's
relative.
John Boyer: nodeset is evaluated
relative to context but the author can't really tell that it is not
being evaluated relative to the "parent
Leigh Klotz: Maybe the name @parent is
the problem.
John Boyer: Is's the context of the
insertion.
Nick van: @parent is used only when
@nodeset is empty or isn't specified.
Erik Bruchez: [joins]
John Boyer: the name
parent makes more sense if the nodeset is evaluated
relative to it, but then @parent would create a special exception
to the relationship between context and nodeset
Steven Pemberton: I think we agree
with the need and the use-case. Would anybody argue against
it?
Steven Pemberton: We can call it
parent for the time being. What I'd like is to go with it and add
the necessary text plus examples.
Leigh Klotz: Which version do we
take?
Steven Pemberton: The two latter
ones.
John Boyer: The name parent makes
sense for the first one. But we don't want to create that special
relationship between context and nodeset only on insert, so the
word parent may be a bit less useful. For what it's worth, the
issue is that in use cases where you would use @context, the
@parent=. and the author can't tell anyway, so it
won't look weird.
Nick van: Why do you need
@parent=. then?
John Boyer: For backwards
compatibility. There's no need to.
Nick van: Why do we need the
attribute? With @context and @nodeset isn't that enough?
John Boyer: No, with @iterate, we need
context() or . inside insert/@origin because we need
the reparenting ability of @context but not the in-scope evaluation
context.
Steven Pemberton: How about @location
instead of @parent?
Erik Bruchez: Or @into.
Leigh Klotz: Or under.
John Boyer: position="under'?
Leigh Klotz: @under.
Erik Bruchez: There are two ways to
use insert: inserting into an element, or inserting next to an
element. So if you want to insert a child I like @into.
John Boyer: If we had @into, it could
still be used in combination with @nodeset, but only when @nodeset
not present or is empty?
Steven Pemberton: I'm beginning to
wonder if @into doesn't mislead a bit.
Erik Bruchez: http://www.w3.org/TR/xquery-update-10/#id-upd-insert-into
Erik Bruchez: The attributes need to
reflect the two basic functions: into something and next to
something. That matches the use cases I've seen. XQuery uses INTO,
AFTER, BEFORE.
John Boyer: We have @position once we
identify a @nodeset and an @at. The @at is syntax candy.
Erik Bruchez: You're pretty much
always inserting into something; I guess technically you could have
a list without a parent. But in general you are inserting into
something. In addition you might specify a specific node.
Steven Pemberton: John, can you add
this to the wiki?
ACTION-1845 John Boyer to add http://lists.w3.org/Archives/Public/public-forms/2011Oct/0032.html to XForms 2.0 Wiki. Choose one now, but note that attribute names are TBD.
Leigh Klotz: Would the group be
interested in hearing some proposals for isolation?
Steven Pemberton: Absolutely.
Leigh Klotz: It may be simpler to do
load embedding with event isolation than without it, for
example.
Steven Pemberton: So I mistook your
question to mean I have some ideas.
Leigh Klotz: I want to know if we
should or should not go there.
Steven Pemberton: I'd say if you have
ideas, go there.
Leigh Klotz: It may be that isolation
will come for free, or could be turned on or off.