Forms F2F Cambridge Day 3 Afternoon March 25, 2010

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Leigh Klotz, Xerox (minutes)
Uli Lissé, DreamLab

* Agenda

• XPath 2.0

Leigh Klotz: I suggested on the way to lunch that we consider presence to be an XForms feature, but visibility a host-language (i.e. CSS) feature, and that all we need is to provide the linkage to control form control host-language attributes (i.e. @class) based on data. It may be that we use Orbeon's xxf:attribute for doing that, or it may be we use some model/@bind mechanism, or some other answer to Steven's live document question, but the main point is that presence/absence is an XForms concept and visibility is styling, and we need to bridge the gap, but not enter into the styling area. That lets us use CSS to style checked rows in green with no XForms spec-craft.
John Boyer: So what's presence, relevant?
Erik Bruchez: relevant goes back to the pre-1.1 version
John Boyer: Pre-1.0
Erik Bruchez: The concept would be used to synchronize form control lifecycle in the new UI event lifecycle.
John Boyer: I see. A form control that has an empty nodeset is absent, as opposed to non-rrelevant.
Erik Bruchez: Right
John Boyer: A form control bound to a node of non-relevant data is not relevant.
Erik Bruchez: There might be also be a way to specify absent without using the ref=".[]" hack. It could also be absent if boolean expression on the group.
Leigh Klotz: It would like @if but Erik doesn't want to call it that
Erik Bruchez: It's a short name and I like that. @enabled isn't bad, but ...
John Boyer: What happens in the default case if I have xf:input/@ref for a non-relevant node. What would the control do? It would be present, but it would default to display:none?
Erik Bruchez: Exactly. It allows the non-relevance use cases discussed earlier, consistently.
John Boyer: A new separate feature that you can control and that allows us to describe empty nodeset binding differently from non-relevant MIP.
Nick van: Are non-relevant things valid/invalid?
Erik Bruchez: Yes, they would get events.
Charlie Wiecha: Fully wired up.
John Boyer: If it's not relevant why would I get invalid.
Steven Pemberton: true
Erik Bruchez: It has to dispatch events.
Charlie Wiecha: It's non-orthogonal not to.
Nick van: Then you have invalid non-relevant form controls.
Charlie Wiecha: It's too many special cases to keep track of.
John Boyer: If the control dispatches, it knows relevant and invalid. Language utility is more important than processor elegance.
Erik Bruchez: input/@ref, node non-relevant, invalid (likely), does the control obtain the invalid property for styling? If so what about events?
John Boyer: Who are the events for?
Erik Bruchez: The xforms author.
John Boyer: Then it's not a disconnect.
Erik Bruchez: You would miss some events if the control becomes invalid while relevant.
Uli Lissé: That's close to Uli's concern.
Erik Bruchez: Right. I didn't share that when non-relevant means absent, but now it means alive and well, but doesn't dispatch events until relevant again.
Nick van: It's a bit broken.
Erik Bruchez: The control could keep the events and dispatch them later.
John Boyer: If all that stuff is happening, it's relevant.
Charlie Wiecha: One of Fred Brook's maxims from the 360 was that instructions sets should be orthogonal. There's a lot of use cases and we will shut some of the off.
Erik Bruchez: We used to say that non-relevant stuff was "dead" (event handlers etc). Now we're not saying that; they show values if styled.
John Boyer: We're throwing the baby out with the bathwater. Non-relevant means don't submit, unavailable for processing, no invalid events.
Charlie Wiecha: But value-changed events.
John Boyer: It shows the value but doesn't need the event.
Erik Bruchez: You tell the user but not the form author.
Charlie Wiecha: You're not allowing the machine user to find out what's happening with that value.
Erik Bruchez: @if is enough. I can imagine when I want to be informed of the value changed.
Leigh Klotz: That argues for Uli's proposal for a single event with context.
Charlie Wiecha: I agree we should take the decisions together to reduce author complexity.
Erik Bruchez: If you just have state changed and @if then you can do it with one event instead of four, yes.
Leigh Klotz: Can you tell what the old and new values were?
Erik Bruchez: Yes, you could compare old and new if old were in the context.
Leigh Klotz: Is it possible to miss a transition by not listening somehow?
Erik Bruchez: I don't think so.

Erik Bruchez: Steven, does it sound offensive that non-relevant controls dispatch events?
Steven Pemberton: I can't think why it would be.
John Boyer: It's legitimate to dispatch events to an invalid form control when it's not relevant. I thought you wouldn't be able to see the invalidity if it were disabled. When I get the invalid I'd like to see if it's invalid and relevant at the same time.
Erik Bruchez: You can do the same in CSS with rules.
Leigh Klotz: There's something funny about not; what is it?
Nick van: We have valid and invalid.
John Boyer: I don't think an aspect of XForms should be governed by CSS showing or not.
Nick van: CSS can only show what is there; non-relevant is still there. I'm not sure about showing non-relevant stuff.
Leigh Klotz: Isn't that the case we want to explore.
Charlie Wiecha: Steven's case, but we don't want to show non-relevant invalidity.
Leigh Klotz: That's the CSS selector of relevant and invalid.
Nick van: I think less than 20% of non-relevant things we want to show.
Steven Pemberton: If we just gray it out but doesn't change, is that a bug. For instance, Google has an image viewer which greys out the back of the screen. In fact, it's trickery, a snapshot.
Leigh Klotz: The master-detail case stepping through non-homogeneous type records blows that up. It has to change types and controls at least.
Steven Pemberton: OK
John Boyer: You could delete nodes of data and they would become, what, absent?
Leigh Klotz: Yes.
Charlie Wiecha: If you have an object embedded it's a meta-file snapshot, not live until you give it focus.
Nick van: ...
Charlie Wiecha: It's work for the filtering.
Erik Bruchez: The UI events don't work anyway. We had to do them in a different way. Do we break things? Non-relevant with empty nodeset binding will get the same effect.
Nick van: But not the relevant MIP. There was no difference and now there is.
Erik Bruchez: It feels wrong because it's a different relevance.
Nick van: It should be the same as if the node were deleted.
John Boyer: That has to not be the right conceptual model because it has to be there to obtain the MIP and transition back.
Leigh Klotz: You can do setvalue and calculate and output/@value on non-relevant nodes.
John Boyer: I believe relevant means absent. If we want gray and uneditable, that's disabled.
Erik Bruchez: I thought we needed two things but now...
John Boyer: We need two things; just which two? disabled in HTML4 tracks changes.
Leigh Klotz: Is disabled about form controls or nodes in your proposal?
John Boyer: I'd like to say it at either level; relevant but disabled.
Erik Bruchez: Then is it different from readonly?
Leigh Klotz: I think HTML4 uses disabled to mean readonly.
Erik Bruchez: readonly doesn't mean grayed out either. Why use html4 disabled? It's easy to implement.
Leigh Klotz: The grey styling is a default.
John Boyer: readonly isn't grayed out. Disabled is not submitted.
Leigh Klotz: OK, readonly isn't grayed out. I was wrong.
Erik Bruchez: So readonly is just CSS?
John Boyer: Under Firefox readonly is different from IE7. The background is grey.
Leigh Klotz: So HTML4 disabled is present doesn't submit a value, and you can turn it off and on with JavaScript, which for us means it's a MIP.
Charlie Wiecha: And you can clearly change the value.
Leigh Klotz: Disabled is present, but not submitted, and readonly.
John Boyer: It's not readonly. readonly data is submitted.
Leigh Klotz: I mean the control is not editable.
Steven Pemberton: That's relevant. The relevance MIP affects the CSS :disabled property.
Leigh Klotz: So we keep relevant as is, and change controls bound to empty nodeset to be absent, and we add a programmatic way to cause absence, perhaps @if.
Erik Bruchez: Leigh pointed out the hiding can be done with CSS.
Steven Pemberton: So our new model-based switching can do what we want from other use.
John Boyer: Non-selected cases of a switch are then absent.
Steven Pemberton: Yes.
Erik Bruchez: How about a hidden case that keeps track of events. Then you can't use switch.
Steven Pemberton: Use user properties.
Erik Bruchez: Then you have to create your own component to re-implement switch.
Steven Pemberton: Just suppose blue-sky we had a MIP that said

<bind class="if . < 0 negative else positive" ref="number" />

Erik Bruchez: Explaining xforms UI events easily is like this:... you get the events when teh form is alive.
John Boyer: Or you get just one event with context.
Erik Bruchez: As long as the control is alive.
Nick van: You need the old values as well. It gets complicated. if @relevant and @new-readonly-state ! = @old-readonly-state
Erik Bruchez: There's a benefit from a single event and a benefit from the new event. That's different from whether you dispatch events for non-relevant controls.
Nick van: Everybody needs to switch to the other thing then if they're using relevant.

Nick van: It's a lot of work to change forms.
Leigh Klotz: We have to evaluate the work but the threshold isn't zero.
Erik Bruchez: We don't dispatch events or update non-relevant form controls. We implement our proposal: non-relevant means dead.
Leigh Klotz: It says the handlers are not there.
John Boyer: No XForms events.
Steven Pemberton: DOM tree disabled with events bubbling through?
Erik Bruchez: Then event handlers outside the non-relevant group can handle the events.
John Boyer: It's a set of things we all agreed to at the time. Less-likely forms are less interoperable. This is the day we put it off to.
John Boyer: The lowest-hanging fruit change is relevant=absent and if you want to gray it out then it's something else.
Charlie Wiecha: That's where I was.
Erik Bruchez: That's the easiest spec change.
Leigh Klotz: It's what you've already implemented.
John Boyer: It avoids a massive architectural shift.
Erik Bruchez: We've realized some fundamental areas we don't have agreement on yet.
John Boyer: relevant=absent is the easiest to explain though.
Steven Pemberton: I'm pretty sure we chose relevant to match HTML4 disabled.
John Boyer: Except you can see disabled stuff and that's not what we picked by default.
Steven Pemberton: That's something different from saying it's not there.
Erik Bruchez: What is your default?
John Boyer: It takes up white space and you have to do work to get no space or shown.
Leigh Klotz: Is that a change for you to relevant=absent?
John Boyer: Yes.
Erik Bruchez: My concern is not the smllest change but for clear results.
Nick van: We only have hiding with relevance
Steven Pemberton: Not absent
Nick van: Completely absent. Our customers love it. There's no demand for :disabled. They don't like that in HTML4.
Erik Bruchez: It's a possibility but I'm not entirely happy. I'm almost convinced that Steven's relevance is nice to have even though I don't need it.
Leigh Klotz: Can we answer Steven's relevance case with some macrology?
Erik Bruchez: You wouldn't get prune with macrology. It's UI-only.
Leigh Klotz: Having just one bit for relevance isn't very flexible even in Steven's credit card use case. Writing it all in UI .[] predicates isn't it either. So that's why I like the custom MIPs or bind or xf:attribute and be able to have shades of relevance participate in different pools, and use host language (CSS) to control display.

Steven Pemberton: The effect of relevance on controls. There are two good use cases. Here they are named HTML4 and Erik:

Erik Bruchez: [leaves]

Steven Pemberton: It's a UI control issue, not a model property, events and presence.
Nick van: If it's present in the UI there should be events.
Steven Pemberton: And handlers.
John Boyer: In HTML4 does a disabled control get events?
John Boyer: And XF11 says "gets events but no handlers" but that's because that's what we agreed at a moment in time.
Steven Pemberton: That's what it is now.
John Boyer: The conversation included a recognition that we were describing something "good enough for now." Changing to "no events" might be reasonable as it's probably at least as interoperable.

Steven Pemberton: One position is that for 1.2 the spec for relevant ought not change.
Leigh Klotz: Or maybe we should switch to an administrative topic.

* Charter Renewal

Steven Pemberton: Invited experts must apply.

* Call Next Week

Charlie Wiecha: I'll be on vacation.
Leigh Klotz: I can make it.

* Next Planned Meeting

Steven Pemberton: Lyon, in November. We can have a virtual or located meeting in the interim.
John Boyer: Can we go for four days?
Charlie Wiecha: Let's go for it.
Nick van: Two is too short.

Action 2010-03-25.1: Steven Pemberton to inquire about 4-day Forms WG meeting at Lyon on November 2010.

* Meeting Ends