W3C Forms teleconference August 29, 2007

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Mark Seaborne, DreamLabs
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair, and minute at end)
Keith Wells, IBM

* Agenda


* Previous minutes:

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0062 IRC supplement: http://www.w3.org/2007/08/22-forms-minutes

* SMIL 3.0 (which uses XForms features to define state, so it is important to read it)


Steven Pemberton: Who would like to review this?
Charlie Wiecha: I will.
Steven Pemberton: So am I. We have until 14 September. I propose we add it to the agenda of the F2F and discuss it briefly there; everybody OK, anybody object?

Resolution 2007-08-29.1: We add SMIL 3.0 review to F2F agenda

Charlie Wiecha: They showed up in Amsterdam last November and we had a good discussion.
Steven Pemberton: Yes, and we discovered they had many more similarities than either of us had suspected. For example, non-relevance (not in timeline). They thought that they were a special case but we discovered it was just a different view on the same thing.

* Next FtF - Hosted by SATEC September 12 to 14, 2007

Attendance Questionnaire: http://www.w3.org/2002/09/wbs/34637/ftfsept2007/
Steven Pemberton: Anybody staying in center of town?
Charlie Wiecha: I'd be happy to share taxis and stay downtown.
Erik Bruchez: I'm not yet sure I can make it but I'd like to try. It's unlikely I can make the first day.
Steven Pemberton: Roger sent regrets.
Erik Bruchez: If I fly in on Thursday ...
Steven Pemberton: I think taxi from the airport.
Erik Bruchez: I think he said it wasn't that close.

* Forms Joint Task Force

Steven Pemberton: A message got sent since last week about the charter.
Nick van: I didn't do anything yet about the charter but I want to contact Mark Birbeck.
Mark Birbeck: I am here.
Steven Pemberton: Another member of the task force from HTML 5 is also on the XHTML 2 WG. Nothing to report yet though?
Mark Birbeck: Not from me.

* XForms Basic 1.0, 1.1

Leigh Klotz: Was the test suite republished?
Keith Wells: It's been updated. I'll get the URL.
Steven Pemberton: Was it going to be published on the W3C site?
Keith Wells: I'm working with John.
Nick van: [irc] don't know if it related but David posted some remarks to the test suite (on www-forms)
Steven Pemberton: Yes, those are in the agenda.
Keith Wells: http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition3/front_html/XF103edTestSuite.html

Action 2007-08-29.1: Steven Pemberton to publish http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition3/front_html/XF103edTestSuite.html

* Backplane


Charlie Wiecha: We're hoping to go be able forward with an RF group after the vote on that closes, if the group wants to.

* Last Call Issues Open and Ready for Consideration:

Steven Pemberton: I propose we go ahead with Last Call issues.

* i18n comment; Availability of time zone information unclear

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=12 "From this statement it is unclear what kind of indicator the user agent should use to provide time zone information. The same unclearness is in sec.7.10.7."

Charlie Wiecha: It's not clear what kind of additional guidance is necessary; it's implementation-dependent.
Steven Pemberton: The local-date function. Who wrote this text? Has anybody implemented this yet? I'm not quite what teh different is from now().
Mark Birbeck: now() contains timezone information; isn't this normalized?
Nick van: [irc] no time
Steven Pemberton: Issue 69 is a comment from me saying I don't understand either. When you do now() you get the local time plus the indication of to interpret that. We don't have a function to tell you what TC time is but we do have a function to get the local time. You get the current time plus how that relates to UTC.
Mark Birbeck: Yeah, but
Nick van: You get the date and the timezone.
Leigh Klotz: With just date and local timezone you can't tell what the UTC date is.
Steven Pemberton: This looks like the result of confusion.
Mark Birbeck: Can I suggest that we hold over. My recollection was that this was raised by David and I remember quite a long discussion on this. I think it had to do with normalization. Mark?
Mark Seaborne: I'll ask David.

Action 2007-08-29.2: Mark Seaborne to ask David Landwehr about http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=12

Steven Pemberton: I think it's imperative that we add examples. It's on hold awaiting response. We'll keep all those issues on hold.

* Let required and other MIPs affect UI control rendition


Steven Pemberton: We specify the relationship between the properties and the controls in different ways and we should word it consistently; and furthermore, for readonly it says "should" and for required it says "may" and relevant says "must." My comment was that the processor should provide a value in controls, not only a may.
Leigh Klotz: relevant is different because it presents or not; required is styled with CSS presently in systems with CSS but we have to allow for it without CSS. Authors should still have control.
Mark Birbeck: We started an initiative to standardize CSS but it didn't go anywhere.
Leigh Klotz: I don't care about the rules, just that the selectors are there.
Steven Pemberton: So that says that processor should provide default behavior.
Steven Pemberton: Does anybody object to changing it so that processors should provide it for required?
Mark Birbeck: Seems pretty harmless.
Nick van: As Leigh says, it must be controllable by the author.
Mark Birbeck: Can we say that the author should have control?
Steven Pemberton: I just don't like it when there is no default presentation.
Nick van: ...
Steven Pemberton: So your only worry is that the user agent might do something that you can't override?
Nick van: Yes.
Leigh Klotz: Yes.
Steven Pemberton: I've no problem with making it clear that it should be overridable. So will make it should here and the author should be able to override it?
Leigh Klotz: Are we going to change readonly as well?
Steven Pemberton: I hadn't asked for it.
Leigh Klotz: Relevant is different because of its behavior.
Mark Birbeck: We decided relevant had behavior but you can still control presentation with CSS.
Steven Pemberton: We should at least say something about type and calculate and constraint, that type may have an effect and calculate and constraint do not.
Leigh Klotz: Do you need to say that constraint does not have an effect? Because that blocks experimentation.
Steven Pemberton: We should say there is no requirement. And invalid as well. So this is a comment about consistent treatment of the MIPs. For calculate, constraint, and type, they need not affect the presentation. Type may.
Nick van: Don't you want so indication that the value doesn't meet the constraint or the type requirement?
Steven Pemberton: OK, I see. So you're saying there should be a should for invalid values?
Nick van: The same text as in required.
Steven Pemberton: That works for me. The type MIP need not affect the presentation but there should be an indication when values are invalid.
Leigh Klotz: The type MIP "may" affect the presentation.
Steven Pemberton: That's good.
Leigh Klotz: For invalid, that's xforms-invalid, not type type MIP. That's the pseudo-property.
Steven Pemberton: We also have a pseudo-property for required. I'm not sure who we give the responsibility to for the invalid display.
Leigh Klotz: This is the conundrum.
Steven Pemberton: The question is who creates that state. The invalid property is how the author controls it.
Leigh Klotz: It seems to be that ought to be the invalid event.
Steven Pemberton: I bet it doesn't say that.
Leigh Klotz: Yes.
Nick van: Is the invalid event always sent? There are cases where other events aren't sent. When starting the invalid event isn't sent. You won't see it.
Leigh Klotz: Good point.
Steven Pemberton: Can invalidity come from anywhere other than a type MIP?
Nick van: Schema, constraint.
Steven Pemberton: Then the requirement that invalidity be made visible has to go somewhere else. We need to resolve something that says that controls bound to invalid values should be presentationally different? Does anybody object?
Nick van: The border case is when the form is initially loaded. Most of the controls will be invalid and we have customers who don't like all the controls showing invalid.
Mark Birbeck: We have an additional pseudo-class called visited; if invalid and visited, so with a red border. As you tab through it, you get more and more red appearing. Our customers are happy with that compromise.
Steven Pemberton: So you load it with initial data which makes it invalid.
Nick van: Or empty.
Steven Pemberton: We've solved the empty case.
Mark Birbeck: We solved it in a horrible way by allowing empty.
Steven Pemberton: You mark them as required then.
Mark Birbeck: We've changed the wording of the same problem; if you indicated invalid and required fields with a red border then you've got the same problem.
Steven Pemberton: People don't like seeing the forms invalid before they've gotten there?
Mark Birbeck: Yes. Users feel they haven't done anything wrong yet.
Steven Pemberton: Everybody's used to forms that say "this field is required" before you start typing. So in XForms 1.1 it goes from invalid to required.
Mark Birbeck: Now you're talking about styling; required is more subtle.
Steven Pemberton: That's the difference; values are required, not invalid.
Mark Birbeck: If you have either integer or empty, then you're saying that fails required.
Steven Pemberton: The datatype is xforms:integer, which is xsd:integer or empty, then you say required=true.
Leigh Klotz: I think it's OK for your visited class modulates the presentation; it's just that the should means that it should be presented. Does everybody agree?
Mark Birbeck: I think so.

Resolution 2007-08-29.2: required and invalid fields should be presented specially, and form authors should have control over presentation and processors may vary the presentation style and time and processors should use CSS if it is available.

* Issues with sending value changed and MIP events

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=29 http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=50

Erik Bruchez: We have both events; they are for listeners on user interface. There are other problems in the specification, but one of the problems is that during initialization we just don't know. Let's say an event handler tries to track whether the first name is valid by listening to xforms-valid and xforms-invalid events; you miss the initial state. So you won't know.
Steven Pemberton: So it's really up to implementers. I think it looks like a good suggestion.
Erik Bruchez: Another issue we discussed briefly with John there was whether we should dispatch xforms-value-changed; this only talks about MIP events and says that they are not done when initialized.
Nick van: [IRC] http://www.w3.org/TR/2007/WD-xforms11-20070222/#rpm-init Perform the behaviors of xforms-rebuild, xforms-recalculate, and xforms-revalidate in sequence on this model element without dispatching events to invoke the behaviors.
Erik Bruchez: But the names are not -changed but set. So are implementers using it?
Mark Birbeck: I hadn't spotted that the events aren't fired during initialization.
Nick van: Yes, it didn't work in my form.
Mark Birbeck: I see why it happens; to clarify events we moved them into that extra phase of refresh. But there is no refresh on initialization. They used to be in initialization.
Erik Bruchez: That may be possible
Leigh Klotz: [off, phone dropped]
Mark Birbeck: I agree that it is odd that the CSS treatment and the event treatment happen differently ... it used to be different to this
Leigh Klotz: [irc] it wont let me join
Erik Bruchez: We optimize this case ... but if you have 400 controls, there will be quite a lot of events
Mark Birbeck: We want to do save and resume, and so we need the initialization events...so I agree strongly with you , and we should reinstate this (I hadn't realized it was gone)
Nick van: I think it was an erratum on 1.0
Leigh Klotz: [irc] I have posted a use case for xforms-value-changed on instance replace, to handle "errors" depending on the returned instance.
Mark Birbeck: I think it is a side-effect of the change to refresh
Charlie Wiecha: MIP events but not value-changed, yes
Mark Birbeck: We can't resolve this now. Need John to tell us whether it was changed by mistake
Nick van: Here is the erratum that removed the sending of the events on construction http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E29a
Steven Pemberton: ... let's put this off to the FtF

Resolution 2007-08-29.3: We continue to discuss http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=29 http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=29 at the F2F

* IRC Log


* Meeting Ends