W3C Forms teleconference November 23, 2011

* Present

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]

* Agenda


* ODF Report

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

* insert/delete @context


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.

* Load Embedding

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.

* IRC Minutes


* Meeting Ends