John Boyer, IBM (chair)
Kenneth Sklander, Picoforms
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Paul Butcher, x-port.net
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Keith Wells, IBM
Charlie Wiecha, IBM
Erik Bruchez, Orbeon [joined late]
John Boyer: We haven't had much
news to print.
Leigh Klotz: Yes.
John Boyer: Steven, you're working on
a story.
Steven Pemberton: Yes, in a couple of
days.
John Boyer: So it seems like we should
hold off until we get 1.1 out.
Editor to incorporate Appendix E Input Mode changes from Steven http://lists.w3.org/Archives/Public/public-forms/2008Aug/0052.html
John Boyer: This is on the to-do list. Then there's Submission headers, event context, a link issue. We'll discuss those later.
Keith Wells: There are two test
cases: 2.3.4 for bind without binding attributes, and some SOAP
changes. The other outstanding changes for submission header are
for today.
Keith Wells: On the implementation
report, we're testing nightlies of FF2 and FF3. I'll run through
those results today. There will be updates to the XForms public
extension page in early September.
Nick van: I'm hoping to tackle the problem for testing Chiba, but we're in a release here.
John Boyer: We're still looking at
doing a report for Ubiquity. It's not complete at this point.
Nick van: Is there any work on
annotating the test suite files with attributes for expected
values?
Keith Wells: We're looking into the
Selenium test suite; it's work in progress and we're working
through stumbling blocks right now. I've made the changes in CVS so
far.
Kenneth Sklander: I've reviewed
data types and haven't started structures.
John Boyer: Yes, I misused "XSD." It's
XML Schema, not XSD.
John Boyer: I brought the progress issue up in the HCG. The results is that we must coordinate with HTML WG chairs about Forms Joint Task Force.
Erik Bruchez: [joins]
Charlie Wiecha: We're developing
directions to share at the tech plenary.
John Boyer: Also can you let me know
when to add the Backplane report to the agenda?
Charlie Wiecha: Maybe 5 minutes next
week.
John Boyer: Through our modularization
work and the JavaScript processor work, we're communicating that
W3C technologies are able to be expressed, implemented, and
delivered, without having to involve web browser makers. It's not a
showstopper any more. Through modularization efforts, initiated by
the XHTML2 WG, we're able to get interoperability on the existing
web framework. These are important messages to get through the
W3C.
Charlie Wiecha: So I raised the
question of connection between simplification and backplane. So
John said that if you look at the way Dojo approaches page
construction, it's through progressive enhancement: a set of empty
divs is scripted into more. We can look at simplification, with
additional structures developed under view controls and in the
model. It's a recursive, or iterative process, expanding the
content, and then the the view. So a more general message about the
simplified syntax might be a progressive expansion.
John Boyer: I've been waiting for the
forms joint task force to bring up the ARIA argument and ask for
xf-calculate and xf-datatype. Those might be more palatable. What
do you think?
Charlie Wiecha: We're just starting to
think about it for Ubiquity. I had thought of using a namespace,
but we might want to revisit that.
Leigh Klotz: So how many tests do I
need to check? Do you validate it as chair? Does Kenneth assert it
has passed?
Kenneth Sklander: The test suite was
from 2005. Did you record what was done then? I have made notes on
the changes incorporated in the test suite in the margin. Those
have all been incorporated in the test suite.
John Boyer: How many tests are
reported? 100 or 400?
Kenneth Sklander: More like 100. It's
the entire 1.0 test suite.
John Boyer: So it's 1.0 first edition
test suite.
Kenneth Sklander: Yes.
John Boyer: Then we won't run the
second or third edition test suite at this point.
Kenneth Sklander: No.
John Boyer: We have the 1.0 first
edition reports from others. As long as the implementation report
says it is on first edition.
Leigh Klotz: So this is XForms 1.0
Basic Profile First Edition.
John Boyer: Yes.
Kenneth Sklander: Is there a test
suite available for the third edition.
Keith Wells: Yes.
Kenneth Sklander: Are there a lot of
things to run?
Keith Wells: It's greatly improved,
and there is a different way of running the tests.
John Boyer: Numerically speaking,
there are over 400 tests.
Keith Wells: No, that's in 1.1.
Kenneth Sklander: We have the 1.1
product now.
John Boyer: Does the XForms 1.0 Basic
refer to which 1.0 edition?
Leigh Klotz: So do we want an XForms
1.1 Basic?
John Boyer: Maybe.
Leigh Klotz: There won't be an XForms
1.0 TE Basic implementation report.
John Boyer: So we should go forward
with XForms 1.0 with its reference to basic profile. We should
consider XForms 1.1 if someone wants to do the tests.
Leigh Klotz: And for XForms 1.2 there
is no need because it's all modularized.
John Boyer: Right. So we can publish
the implementation report in our dated space.
Leigh Klotz: And I'll make sure that
the reference from XForms 1.0 Basic is to the dated specs.
Nick van: No progress yet.
John Boyer: CR is the implementation period, but do we need to go back to last call? No alarms are up for me yet but if you see any issues, please let me know.
John Boyer: We expose the context
but we don't expose the the target. It's fairly easy to add in the
event function. It's the regular XML Events pieces of data. It's
going to mean more test suite work and more implementation work.
Does anyone else feel that the event function is broken as a result
of not providing the event information? Is there some reason to
prefer that it doesn't provide that information?
Erik Bruchez: I want to expose it but
I don't have an opinion for 1.1 or not. In our implementation, we
export target and event name. We expose custom information as well:
bubbles, cancelable, etc. We also have a facility to add custom
context information. The most useful one is the target, and the
event name can be useful.
John Boyer: This isn't as big an
oversight as with submission, but it is an oversight. It's
localized to the event function.
Leigh Klotz: Let's see if we can
capture the questions so we can repeat them next time, because
eventually we'll have to say no. Is anybody opposed to the feature
in general? Is it important to have? Is it important to have now,
or can we wait? Does it cause last call? If so, does it cause
limited last call?
Erik Bruchez: That's a good analysis.
I think there are a dozen or so things of this level and we should
push them out.
John Boyer: Good point. Thanks for the
analysis Leigh. We'll push this forward.
Duplicate headers same keyname more than one value.
Leigh Klotz: It worries me that the
appending and the accept-type corner cases are the ones raised by
implementers.
John Boyer: Then do the rest
later.
Paul Butcher: Appending can be handled
with concat.
Leigh Klotz: I don't think you can
access the current header to concat. I don't think we can legislate
what HTTP serialization does with Accept-Type because we don't have
a good interoperable and useful suggestion yet.
John Boyer: So can you write the
note?
Keith Wells: We need to be lax on
how it can appear?
Leigh Klotz: For generic headers, test
and accept either serialization in HTTP but for accept type, it's
vague.
Keith Wells: Here are some other
issues with multiple xforms:headers each with multiple xforms:value
and multiple nodes that match.
Leigh Klotz: For headers of the
same name, I'd say we go with document order for the xf:headers,
followed by instance order of the nodeset, followed by document
order of the xf:value within the header. For headers of different
names, there is no need for order testing.
John Boyer: Why is uniformly appending
not implementable?
Leigh Klotz: Because it needs to be
moved to the HTTP serialization section, because the protocol
decides what append means. We can restrict to just one header with
multiple values, but I'm not sure what it buys us.
John Boyer: It doesn't buy us
much.
John Boyer: Can you proceed?
Leigh Klotz: I can write the text but
I'm worried that nobody would implement it. It lets us set the
headers that are not set, but there's no way to say what to do with
pre-existing headers, which cuts out the ability to do content
negotiation for REST services.
John Boyer: So a reasonable
implementation could make use of a replace-vs-append flag. And
without it we don't achieve our goal.
Leigh Klotz: We need something, but I
don't know if it's the attribute. We need to say what happens if
you have multiple headers with conflicting values of the attribute,
for example.
John Boyer: Ok. So can you write it
up?
Leigh Klotz: That's the question: do
we do the conservative thing that is implementable but not useful,
or do we go back to the drawing board. So you and I agree, butr do
we have consensus?
John Boyer: Any objections?
Steven Pemberton: [irc] I think the
use case is essential.
John Boyer: OK. So if it doesn't meet
the needs we need to remove it from CR anyway if nobody implements
it. So let's go forward.
Action 2008-08-20.1: Leigh Klotz to investigate replace attribute on header and discuss test cases with Keith Wells and consult with potential implementers and users and provide spec-ready text for XForms 1.1.
John Boyer: So can he do a setvalue
inside the link exception handler to set a value from the inline
instance? We said the processor would be going down anyway.
Paul Butcher: By the looks of it, it
looks like it would do the setvalue, but the default action would
stop processing. But outputs and messages wouldn't happen.
John Boyer: If the instance in the
source attribute were the first, would it matter?
Paul Butcher: That's a difficult
question.
Charlie Wiecha: We might just call
this error in my stuff.
John Boyer: We can't make any change
for 1.1. For 1.2, we'll use this additional xfor-link-error as a
way to get out for the problem. The question is still open about
when he can write to the instance. So we'll take corrective action
in a future version.