W3C Forms teleconference May 21, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Keith Wells, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Doug Scheppers, W3C
Steven Pemberton, CWI/W3C
Rafael Benito, SATEC
Uli Lissé, Dreamlabs

* Agenda


* Previous Minutes

* HTML4 to XForms Onramp

Nick van: There is an HTML4 to XForms converter on sf.net but no license is specified.

Action 2008-05-21.1: Keith Wells to contact sf.net author of HTML4 to XForms stylesheet

* XForms 1.1

John Boyer: The XForms 1.1 CR period has ended. We need implementation reports.
Erik Bruchez: We are implementing features from XForms 1.1 on an as-need basis.
John Boyer: Are you doing an implementation report, a spreadsheet like format?
Erik Bruchez: It would be good to do. Is there a date?
John Boyer: We can't exit CR until we have some implementation reports so the sooner the better. Our CR period ended May 15th. If we need more time to prepare the reports, we can do that. We have none, and need at least one reported implementation of all features and two interoperating implementations of all required features.
Keith Wells: I am working with a co-op student on the Mozilla Firefox XForms extension and have him record the status of the test suite; it's 85%-90% I suspect.
John Boyer: That would be great.

Action 2008-05-21.2: Keith Wells to report on status of Mozilla Firefox XForms extension XForms 1.1 test suite.

John Boyer: When can you do that?
Keith Wells: I'll give status June 15th.

John Boyer: Erik, you don't have to report conformance on every test and you can validate the tests themselves, as they may be testing many related items (events, context information).
Erik Bruchez: Is the latest test available from the working group's main page?
Nick van: [irc] http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/driverPages/html/index.html
Steven Pemberton: [irc] http://www.w3.org/MarkUp/Forms/Test/

John Boyer: Also we can test Ubiquity, reported here last week. There's about 400 tests in the test suite; is by mid-June good?
Keith Wells: I'm hoping to produce a Selenium harness for running the tests.
John Boyer: It will take two days otherwise, even if all test succeed, and more than that for failures to decide what the problem is.

John Boyer: And we can get an implementation report from x-port.net as well.

* Rich Web Backplane

Charlie Wiecha: John, Steven, and I joined and started discussing events. We think events are key for coordinating across the page, and wanted to discuss subsets of DOM events for folks who aren't on it yet. We have Forms, Multimodal, and SMIL represented, and the Forms Task Force, but not Voice yet. We'll report back in a week or ten days. I'm hoping some one from Mark's company will join.

* Implementation Report from Chiba

John Boyer: Does anybody have contacts with Chiba?
Nick van: I'll ask.

* Implementation Report from DataMovil

John Boyer: Rafael?
Rafael Benito: We are doing testing but will not be able to do an implementation report at this time.

* XML UK Group

Steven Pemberton: The XML UK Group are interested in organizing an XForms event. When there is firm information I'll announce it.

* Action Items


Steven Pemberton: I've done triage on paper and am typing it in.
John Boyer: Good. But we're not making as much progress as we want.

* Fix definition of Validity (TBD May 21*)


Uli Lissé: I would like to have required-but-empty as part of validity, but we have another annoyance: we have many parts: the constraint MIP, the data types, and maybe required-but-empty, and it's hard to differentiate. I'd like to have context in the invalid event. The constraint failed, or requiredness, or datatype.
Nick van: You probably also want access during styling in HTML. I think if we change it, you also have a problem with alert showing because it's invalid, when the form loads. The styling isn't normative, but that's what people will implement, if we don't specify more.
John Boyer: I liked Leigh's suggestion about empty.
Leigh Klotz: We always wanted full value access on CSS, but maybe just empty is good enough for now.
Nick van: And type info and other MIPs?
Erik Bruchez: I support the new context info and other point enhancements, but I'm a little worried that this small validity change triggers a lot of changes. Maybe the styling doesn't need to go for 1.1, as it's non-normative. The same can go for context. I'd like to see the implementers experiment first, report back, and have us incorporate it in later revisions.
John Boyer: I don't want us to change something in the spec that requires something such as a pseudo-class to be added but it's not in the spec. Isn't that a bit strange? Shouldn't we ensure that current behavior is possible.
John Boyer: You could force 1.0 behavior. In an event handler you can find out whether a node is empty or not. You can't find out if it was a constraint or a type that failed, but we could take that under advisement that we need more context information. This isn't the only thing that's come up. I'm curious; in CSS, how do implementers decide when classes need to change?
Erik Bruchez: In our implementation, it's super-refresh done on every exchange between the client and the server.
John Boyer: Your implementation is not dependent on receiving an xforms-valid or -invalid event?
Erik Bruchez: No, it's not. We don't use the UI events to update the classes.
John Boyer: Good, because it wouldn't work anyway.
Erik Bruchez: I remember the debate, but we use the events only for communication with authors. The information is reflected to the control during refresh, as the spec hints.
John Boyer: If we'd had @if and context information in XForms 1.0 we wouldn't have needed this proliferation of readonly/read-write, valid/invalid etc. events. It would have been a new refresh MIP event. People could have said "if the validity MIP is invalid" and show something.
Leigh Klotz: But do we have this context info now?
John Boyer: No, but I agree with Uli's suggestion for the future. Not for 1.1. As for the class, I think a boolean empty-or-not-empty.
Leigh Klotz: That sounds like it's part of my uncompleted action item.
John Boyer: Yes, can you get on that?
Leigh Klotz: OK.

Leigh Klotz: By the way, here is the draft newsletter. Please let me know if anything important is missing: http://www.w3.org/MarkUp/Forms/wiki/March-May_2008_Newsletter

John Boyer: Nick, would a styling example on invalid+empty with the new empty pseudo-class help you? Can you live with that.
Nick van: I can live with it. I just want us not to make spec changes that break things.

John Boyer: Keith, can you ask Aaron Reed if the empty pseudo-class is implementable in Mozilla?
Keith Wells: He's not online right now.
Leigh Klotz: Mozilla has a -moz-type psuedoclass for MIP type, so it should be possible.

John Boyer: OK. I think we're getting close. Proposal: Change definition of "valid" to include "required and non-empty OR non-required" and that the definition of invalid includes "required but empty." And submission validation can then just refer to validity tests defined in the section on xforms-revalidate. And CSS appendix should add definition of empty class and example of how to style "invalid but empty"
John Boyer: Is this a 1.1 or a 1.0 erratum? Anybody have opinions on 1.0 issue?
Erik Bruchez: I don't have a strong opinion. I think we're all moving to 1.1.
Leigh Klotz: I heard PicoForms isn't moving to 1.1 yet but they don't have a representative here.
John Boyer: We should go back and ask them if they want this change to happen in 1.0. If the WG feels we should just focus on 1.1. Does anyone want us to go back and find out?
Leigh Klotz: You can forward a pointer to these minutes to Mark Seaborne and if PicoForms wants some XForms 1.0 changes they can come to the meeting and discuss it, but failing any push we should just make this at XForms 1.1 and beyond.
John Boyer: OK.

Erik Bruchez: The name "empty" is taken already in CSS3 draft.
John Boyer: How about value-empty?
Leigh Klotz: Or empty-value?
Nick van: [irc] value-empty is fine for me.
John Boyer: We could extend value-* into constraint, mip, etc.
John Boyer: What is the current class for valid?
Uli Lissé: :valid and :invalid
John Boyer: So Uli's suggestion would :invalid-empty

John Boyer: I guess we already have :valid and :invalid historically without referring to the value. As for the overall proposal of the four points?

Erik Bruchez: It's not +, that's the sibling combinator.
Leigh Klotz: Like this? xf|input:value-empty:invalid
Erik Bruchez: I think that would be the proper syntax.

John Boyer: value-empty or empty-value?
Charlie Wiecha: I like the value-* ones for the reasons John mention.
Leigh Klotz: Do we need to revisit valid and valid then when we add more?
John Boyer: Proposal: change valid/invalid definition to account for required but empty, change submission validation to match, and add CSS pseudoclass and example for "value-empty"
Uli Lissé: [irc] when we want to add :invalid-constraint, :invalid-type later, I'd still prefer :invalid-empty
John Boyer: [irc] it would actually be invalid-required
Uli Lissé: [irc] ok
John Boyer: [irc] it is invalid because it fails the required condition

John Boyer: Anybody need more time on this?

Resolution 2008-05-21.1: change valid/invalid definition to account for required but empty, change submission validation to match, and add CSS pseudoclass and example for "value-empty"

Action 2008-05-21.3: John Boyer and Leigh Klotz to change valid/invalid definition to account for required but empty, change submission validation to match, and add CSS pseudoclass and example for "value-empty"

John Boyer: You and I can change about the CSS.

* xforms-submit-done response-body and host language submit result targeting


John Boyer: Perhaps they want replace="_blank". It's not clear what they want to do. This caused me as a tangent to notice that if the xforms-submit-done has the response body then a script could capture the event with replace=none and listen for the event and take the content and ship to another window. I don't know how reasonable that is, but the point is that it's not possible because we don't include the response body in the xforms-submit-done
Erik Bruchez: If you do this as in the processing-model, you read the stream, get the document, do the replacement, then dispatch xforms-submit-done, there's no context information and you don't need to keep the result of the HTTP response. If we add this you would need to store the body somewhere. In our implementation, we don't keep the body as text, so when there is an error, we won't be able to return a response body for XML parsing errors. So if you want to implement xforms-submit-error you may need to keep the body.
Leigh Klotz: If there is no other case other than XML parsing error when you have to hold on to the response for a long time for xforms-submit-error, couldn't we say that xforms-submit-done only contains the body in the case of replace=none?
Erik Bruchez: In the case of replace=none couldn't we just read it then?
Nick van: [irc] I don't think chiba reads the body with replace none
John Boyer: xforms-submit-done is sent after the body is read.
Erik Bruchez: So you have to read the body and we could say if it fails you return an empty nodeset.
John Boyer: It doesn't have to read it so much as make it available. [reads text]. It define whether it includes a body or not. So at a minimum, we know in the replace=none case whether we have a response body or not. So it's something we could provide. Why would we limit it to replace=none?
Leigh Klotz: Then you hold only one copy, replace=instance gets DOM and replace=text each store only one copy of the response.
Erik Bruchez: We still have to hold on to the response for XML parsing errors to signal xforms-submit-error.
Leigh Klotz: That can't work arbitrarily, because a 2^31-1 byte document consisting of "<" won't be held onto as text. So it's unwise for authors to depend on the xforms-submit-error context information for replace=instance when the content-type is XML.
Erik Bruchez: I'm not sure.
John Boyer: Should we do this for xforms 1.1?
Erik Bruchez: If it doesn't take too much time, then we can do it, but if we still have doubts...
Nick van: [irc] we are past last call...is it really needed?
Charlie Wiecha: [irc] -1 defer
John Boyer: OK, we put it on the list of things for the future. When we do replace=blank in the future we'll work on it then and maybe get a better solution.

* IRC Log


* Meeting Ends