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
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.
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.
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.
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
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.
Steven Pemberton: I propose we go ahead with Last Call issues.
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.
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.
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