Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Sebastian Schnitzenbaumer, Dreamlabs
Steven Pemberton, W3C/CWI
Uli Lissé, Dreamlabs
Keith Wells, IBM
Roger Pérez, SATEC
Blake Jones, DAISY/ViewPlus
Erik Bruchez, Orbeon
John Boyer: We might want to record the event. Anyone do that regularly? It might be a good idea to figure out some way to get it recorded.
Charlie Wiecha: We now have a third
option for patent policy for backplane, for cross-group
collaboration.
John Boyer: Can you send a short
message to the group pointing out what the third option is, why
it's important, and a link. I'll put it on the F2F list.
Charlie Wiecha: It allows us to adopt
the same patent policy for incubator groups that we do for working
groups, a concern of Voice WG.
John Boyer: That's great news. Is that
announced to W3C?
Charlie Wiecha: It's on a member page,
but I'll describe it.
Steven Pemberton: This call will,
for one week, be an hour different for Europeans. I will send
mail.
Nick van: [irc] one hour later I
guess
Steven Pemberton: Then the week after
that it will be back to normal because the US changes, but hat is
the F2F of course.
John Boyer: Jim Larsen and Debbie
Dahl said that Voice and Multimodal were meeting on Tuesday, and
MMI was also interested in talking about harmonizing events, so
they raised the question about whether all three groups should meet
on Tuesday.
Charlie Wiecha: I think there is
shorter term progress with Voice on data models, possibly SCXML.
Eventing is more problematic, bubble, capture, etc. The alternative
is two separate meetings which probably don't have time for.
John Boyer: If we don't do it now, it
will be another year.
Charlie Wiecha: Maybe we could take
voice issues first, then multimodal issues.
John Boyer: I don't mind just keeping
Monday with Voice and then Tuesday with both groups on event
harmonizing. Steven?
Steven Pemberton: We could do events
the second day.
John Boyer: Everybody happy?
Charlie Wiecha: I can coordinate the
voice one if Steven does the events.
Charlie Wiecha: I'm done except for
a submission element issue which I sent you.
John Boyer: The Schema will be checked
in today, if you want to look over it.
Nick van: [irc] I've read it and it
looked good I think
John Boyer: You completed
these?
Erik Bruchez: Yes. I can go through
the email. The sections for select and select1, I noticed they
don't tackle xforms:copy. It is described separately, and mostly is
about xforms:value. The changes I made retain that direction. If we
agree, it wouldn't be too hard. There was a message similar to
message 89 about this.
Erik Bruchez: Also, a change for
xf:select1 which wasn't in the message. I harmonized the wording of
select1 with select: I took a more detailed approach in select,
when the control gets a value, when the user selects, and deselects
and propose doing the same in select1.
John Boyer: The harmonizing certainly
sounds reasonable. On the first issue you raised, should value and
copy behave in an analogous way? You're matching strings in value;
with copy you're matching subtrees.
Erik Bruchez: In fact, the spec
doesn't talk about this at all. You could conceivably either match
a deep copy, or just match on the qualified name, or even on the
prefix. We don't specify this at all.
John Boyer: We don't say how to match
them exactly, but I think the word match is fairly clear. If you
only compare the root elements, you could have a schema in which
the root element has a choice so it's not a subtree match. When
copy sets the value it's a deep copy; it's reasonable to conclude a
deep comparison.
Erik Bruchez: Yes. I think that's
fairly reasonable but we don't say it right now. The "algorithm" is
described in xf:copy but it's complete. The "algorithm" for
xf:value is described in xf:select. It's inconsistent. One thing to
do would be to harmonize.
John Boyer: That makes the most amount
of sense.
Erik Bruchez: ..
John Boyer: I've been taking the
approach that if there's something in the neighborhood of a
last-call comment we should fix it. We have a comment about value
but not about copy, but we should fix it.
Erik Bruchez: If the WG agrees I'll
fix copy as well. But I want to be reasonable sure that it's the
right direction first. I heard from Nick but nobody else.
John Boyer: OK. I'll go over that
today as well. Anyone else?
Steven Pemberton: Yes, eventually.
We're reviewing it at the F2F?
John Boyer: Good question. Are we
then?
Steven Pemberton: What are the
options?
John Boyer: If we've reached
resolutions, I hadn't thought we'd spend more F2F time on CR
issues.
Steven Pemberton: I have to warn you
that I saw the word substantive change in a message header and that
rang some ugly bells for me. That means a second last call, I'm
afraid to say. If we ask for a transition to CR and we report
substantive changes since last call, then we'll have to go to last
call again.
John Boyer: We can talk about that at
the F2F.
Steven Pemberton: If the changes
aren't substantive, then it's OK. It would probably be only short,
three weeks to check just certain places.
John Boyer: This particular issue
doesn't call for a substantive change.
Steven Pemberton: No, but it's about
whether we need to discuss CR issues. Just look for "substantive
change" in the header.
John Boyer: I see; the question is
what does "substantive change" mean. I was writing some examples,
but as I was writing them, I noticed that the mediatype attribute
suggested that form authors should make sure the mediatypes they
assign are consistent with application/xml; this isn't true in
XForms 1.1 because we have a mechanism to submit plain text. It's
only a substantive change in that it was a change in not in example
material.
Steven Pemberton: Then that's probably
safe.
John Boyer: If you look at all the
changes for last-call comments, we've changed the verb element to
method element. Is that a substantive change or just addressing
someones last-call issue? It's clearly the same concept, still
implementable. Otherwise it would be impossible to avoid a second
last call for anyone. Should we look through and see if there is a
need for a second last-call?
Steven Pemberton: Yes.
John Boyer: How long did this take for
XForms 1.0?
Leigh Klotz: We had more than one last
call.
Steven Pemberton: If someone says
there is a substantive change we have to discuss it. It might be
good to have that in the minutes of the meeting that we've done the
evaluation, for the transition call.
John Boyer: So a couple of hours at
the F2F?
Steven Pemberton: No, a half hour or
so.
Sebastian Schnitzenbaumer: Just look
at the final version and see if there are big implementation
changes.
John Boyer: I'll put the last-call
issue analysis for substantive changes on F2F agenda.
Leigh Klotz: Should John put the
select material from Erik in the spec now?
John Boyer: Steven wants to review it;
I'll review it adding it in. Steven, are you OK with putting that
text in?
Steven Pemberton: Sure.
Action 2007-10-24.1: John Boyer to include material from http://lists.w3.org/Archives/Public/public-forms/2007Oct/0084.html in XForms 1.1.
John Boyer: And Erik, you'll look at the xf:copy harmonization?
Action 2007-10-24.2: Erik Bruchez to provide spec-ready text for xf:copy harmonization as an extension of http://lists.w3.org/Archives/Public/public-forms/2007Oct/0084.html
John Boyer: Any comments from
Martin Düerst?
Steven Pemberton: We asked him if it
would be more efficient to have the list by reference. He said it
made some sense, but said that it wasn't clear that future versions
would be the same. Because there are changes in spelling, it would
be more useful to have the whole list.
John Boyer: [irc]
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Appendices?id=106
Steven Pemberton: So his official
answer is no.
John Boyer: So we have to update the
list?
Steven Pemberton: Does anybody
understand the list item?
Leigh Klotz: Martin gave us this list
the first time as he was on the WG. Maybe we can ask him to do it
the first time.
Steven Pemberton: Then just give me
the action.
Action 2007-10-24.3: Steven Pemberton to ask Martin Düerst to provide updated list of scripts for http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Appendices?id=106
John Boyer: Steven, this is the
required property, respecting it, showing it, etc.
Steven Pemberton: Let me do that
Friday.
John Boyer: We'd agreed to add a
description of changes to section 1 of the spec and you'd provided
some text; could you find it for me?
Steven Pemberton: Someone took it in
Madrid and was going to turn it into XML Spec. Sebastian?
John Boyer: Sebastian wasn't
there.
Nick van: I was doing it; I spent
quite some time on it but it's hard to convert it to something we
can put in the spec. I was trying to add references to relevant
sections; now it's just bullets.
Leigh Klotz: Why don't we just publish
it as a note then.
Steven Pemberton: Or just list it as
bullet points. I think, quite honestly, it would be good to have in
the spec.
John Boyer: If we wanted bullet points
now and then links later, then that's ok as it's not
normative.
Steven Pemberton: You could put in in
as an informative appendix.
John Boyer: A larger description, yes.
Then later down the road you can make later links.
Nick van: I can send in what I have
but it's also not...I tried to use ordered lists and specXML but
I'm not sure if I'm using the right ones. Maybe you can fix the
exact structures.
John Boyer: I can do that and send it
back to you. Do you have an action item on this? I can plug it into
XMLSpy for the DTD.
Nick van: Yes, it is valid. I removed
formatting and tried to make it look like spec text and that was
more work.
John Boyer: Is there a scaled-down
version you can do in the next week or so?
Nick van: Yes, I'll send it in.
Action 2007-10-24.4: Nick van den Bleeken to send current version of spec-ready-ish text of changes to list.
John Boyer: I've asked Erik if we
can defer this.
Erik Bruchez: It's a multi-dimensional
issue. There's the name issue, for example. I think it may take a
bit of time to figure out what we want and the implications of
changes.
John Boyer: Yes.
Erik Bruchez: It's hard to decide
which is which by reading the spec. It's a longer term issue unless
we agree right now. The events cannot be stopped, for example. It's
not very hard but there's more than we can do now. 1.2 or
2.0.
John Boyer: Then we can classify this
as a defer; we acknowledge that we're not too clean on exceptions.
They halt processing anyway. We would like a better analysis of
when we should not halt processing, and what more information we
can give, even for debugging. Everyone OK to defer for now?
Resolution 2007-10-24.1: We defer http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=36
John Boyer: If the XPath expression
parser chokes, we generate an error.
Erik Bruchez: They don't use those
terms static or dynamic. They do specify variable naming, function
mappings...
John Boyer: There is a context. It
wouldn't be too hard to say that thinks like variable references
are wrong. Or function names not in the function library. The only
two other things are the context node position and size and those
are under our control.
Erik Bruchez: Those are part of the
dynamic context; function library is static context.
John Boyer: ... static context
...
Erik Bruchez: In XSLT you can
determine statically what variables are in scope. They may or may
not be in the static context in xslt.
John Boyer: That are not statically
valid, a variation on Steven's suggestion?
Steven Pemberton: I have my doubts
about the word valid; maybe incorrect
Leigh Klotz: Isn't it any error that's
independent of the instance data?
Erik Bruchez: Static analysis is when
you don't run it.
Leigh Klotz: If it's not statically
valid over the domain of all instance data then it's
problematic.
Erik Bruchez: As in XPath 2.0, the
syntax is correct, the function library has to be correct.
Leigh Klotz: I would put in more
stuff.
Erik Bruchez: Just keep statically
correct.
John Boyer: The context is pretty well
defined: expression string, node, position, variables, function
library. So those are the only things that could go wrong.
Leigh Klotz: No matter what the
instance data is you shouldn't get static errors.
John Boyer: We say that already all
over.
Erik Bruchez: We should do it like
XPath 2.0 if we add more text. Instead of saying static context,
include in-scope functions, etc. We don't have variables.
John Boyer: We're out of time. We do
need a resolution. Erik, can you propose text?
Erik Bruchez: OK, maybe next week
sometime.
Action 2007-10-24.5: Erik Bruchez to propose text for http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=139