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
http://lists.w3.org/Archives/Public/public-forms/2008May/0006.html
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
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.
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.
John Boyer: Does anybody have
contacts with Chiba?
Nick van: I'll ask.
John Boyer: Rafael?
Rafael Benito: We are doing testing
but will not be able to do an implementation report at this
time.
Steven Pemberton: The XML UK Group are interested in organizing an XForms event. When there is firm information I'll announce it.
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.
Looking for resolution to make changes identified in
John Boyer: We decided to exclude
required-but-empty nodes from the revalidate event. The discussion
on the list was to fix the problem.
Erik Bruchez: I think we should fix it
as we have two concepts of validity and it causes users problems in
understanding. Last week we couldn't find the rationale for the
current state. I can only see positives for the change.
Nick van: The problem with styling it
in CSS is still there; you can't see if it's invalid because it's
empty, so all required fields are styled in valid.
Erik Bruchez: It's annoying that you
can't style it, but you couldn't style it before. There's no
required-but-empty. In our implementation we had an extra class for
that. But there's nothing in the spec.
Leigh Klotz: Do we need just an empty
class, since you can style on plus?
Erik Bruchez: Possibly that could
work. Nick is right that we can do it. But Nick is right that deep
in XForms we have a confusing concept. There are some use
cases.
John Boyer: In my own host language we
have an empty class; required-but-empty is styled differently from
required-but-invalid, but it's still invalid. It looks more like
people expect. That was the initial worry, that as soon as you
bring up a form with required fields, it has an unfriendly
countenance that says they've made a lot of errors.
Leigh Klotz: When did we do this or is
this future?
John Boyer: We did this as an erratum
in 2006 to change the definition of revalidate to say validity is
defined on the constraint MIP, the type MIP, and schema definitions
only. http://www.w3.org/TR/xforms11/#evt-revalidate
John Boyer: That's the change we made.
Then in submission, http://www.w3.org/TR/xforms11/#submit-evt-submit
point 4 we check for validity according to xforms-revalidate, and
check for any data node that is required-but-empty or invalid, and
if so stop submission process.
John Boyer: So the choice is to stick
with the divergence of validity (one version for submission and
another for interaction), or make one consistent definition of
validity which would require us going back on a prior
decision.
Nick van: [irc] don't we also have a
problem with alert
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.
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.