Erik Bruchez, Orbeon
Paul Butcher, WebBackplane [joined late]
Leigh Klotz, Xerox (minutes)
Mark Birbeck, WebBackplane [joined late]
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
John Boyer, IBM (chair)
Kenneth Sklander, PicoForms [left early]
John Boyer: Erik?
Erik Bruchez: We're busy and it's hard
to promise to do it soon.
John Boyer: It's becoming a blocking
factor for us to get XForms 1.1 to rec.
John Boyer: Is there anyone on the
call who can speak on behalf of Chiba?
John Boyer: We're still working on a report for Ubiquity XForms. We have the Firefox plugin already. I know there are 1.1 implementations out there, but we need to invest to get our spec to rec. Otherwise it looks like we're stalled, when we're not, as the technology is out there and getting into increasingly-wider use.
John Boyer: We have competitors who are in the space of XForms but who do not participate in the XForms WG because they have business models that keep their formats proprietary. We need to quell the FUD.
John Boyer: Can you send it to me
again, Leigh and Kenneth?
Leigh Klotz: OK.
John Boyer: Keith, how many
passed?
Keith Wells: It's wide coverage;
there's a handful that aren't implemented.
John Boyer: Were their any partial
tests?
Keith Wells: Not to my
knowledge.
John Boyer: For example, passing the
event but not the context info.
Keith Wells: There are a few of
those.
John Boyer: Does your report call
those as partials?
Keith Wells: Yes, we made quite an
attempt to do that.
John Boyer: For other reports, that
should generally be the strategy. Knowing which things those are
will help provide us with full converage.
Keith Wells: There are some judgement
calls where the test fails but it meets the spec.
John Boyer: We have a fairly mature
spec for first public WD. There will be further changes as we have
later revisions. I'm excited because we have a way of injecting
XForms model behavior into tagsoup or XHTML host documents, which
opens up the XForms technology to a broader class of documents and
web application developers who will benefit from the modularization
work we're doing. We've taken an attribute decoration approach
because we have access to attributes even when the document is not
parseable XML. There's some inspiration in this model from WebForms
2.0 and HTML5; obviously it's not said in the same way everywhere,
but we have a deliverable as a WG where we merge WebForms 2.0
conceptualization and th XForms architecture. What excites me is
that we have something that projects, creates, generates, a full
XForms MVC connector architecture that then allows people to adopt
elemental modules such as our full submission module or our XML
data instance module or data instance plus operators module, these
things that we've been working hard on during the F2F meetings. So
it's an interesting approach. We have an issue that we have to
resolve about naming it. The name now is "WebFormsA Streamlined
Syntax for Data-Rich Web Applications." I've been a very strong
advocate for the name WebFormsA, not because I want to have one
strike against us with the HTML5 group of people; I think it's fair
to say that we already have that strike, so we're not to appease
that group, but to appeal to the broad web community and show that
we're operating under our mission statement as a working group to
provide forms on the web, and we have a full range of
specifications. WebFormsA is a natural name because we have an
attribute form. It's very much about forms on the web and targets
HTML-like documents. It's broadly written, and we might be able to
get better XForms adoption in ODF as well as HTML. The W3C, as a
standards organization, has changed over the past 5 years. The
competition that's playing itself out in the world is also playing
itself out in the W3C. The economists would refer to this as the
"creative destruction engine." We have to recognize and adapt to
the fact that there's competition in the space that we're in, the
space of forms on the web. We need to communicate and one way is to
publish specifications. When we say "specifications" in the W3C
sense, we mean recommedation-track documents. What excites me is
that in order to carry this to completion, we have to end up
creating interoperable implementations. We're working on this in
the Ubiquity XForms. We will demonstrate the operation and
applicability of this technology to general web pages, and will
leverage the technology we have developed in the Forms Working
Group. We know we have broadly-applicable technology that covers
rich applications, rich web, rich mobile; we know we have
technology that covers all those fronts. We can deliver that in a
way that makes sense to the wider web community, and when we show
it working in Firefox, Internet Explorer, Safari, Opera, mobile
space, it will make sense to the other WGs. When we get our
attribute tags and some fraction of elements client-side without a
plugin, that's an important aspect of our message. Then we can
steer them towards our implementations. That's where the strength
of standards come in. That's my extended sales pitch on why I
believe the WG needs to publish this with the name WebFormsA, to
clearly indicate the space of this document and show we met our
deliverables.
John Boyer: Any comments?
John Boyer: Do we need to make a
"shortname" request for the WebFormsA spec in order to do
FPWD?
Steven Pemberton: I suppose we do,
yes. Do we have consensus?
John Boyer: Any objections on call to
shortname of http://www.w3.org/TR/WebFormsA/
for FPWD?
John Boyer: Once we publish FPWD, it's not a technical issue, so as further drafts are published, they would be about technical issues, not marcom issues. This would be harder to change, but anything's possible. I hear no objectiosn on the call. No idea's perfect; there are drawbacks to every approach, but in my view this is the best overall approach for this WG and I appreciate your support.
Action 2008-11-5.1: Steven Pemberton to request shortname WebFormsA
John Boyer: I have found all we
need to do is tag something with a startsize to mark it a
repeat.
John Boyer: I have seen applications
which want to start with a size of three, but that's all the
indication that we need that something is being repeated. This
starter module won't offer everything that XForms repeat can offer;
for example, XForms 1.1 can bind to nodes with different names and
parents, but that power is available in XForms elements. The
attribute syntax offers XForm 1.0 homogeneous collections. If you
need to define your own data, or cross parent boundaries in the
schema, then you can scale up and onramp. Start low and scale up in
the areas that you need.
John Boyer: Note the instance that
gets generated. This is the mapping. There is one attribute added,
the default="true" attribute. This is not specific to
repeat; we will need this in the Instance Data module. Declared
instance data may be for forms, or may be for submissions for web
services. An XForms instance element with default="true" is the
default instance, the instance for data. Otherwise we'll make a
generated instance. It will be created as the first child of the
form element.
Leigh Klotz: Couldn't this be done in
such a way that it's consistent with what we have now?
John Boyer: So let the default be true
for the first instance and the second not?
Leigh Klotz: However we do it, it
would be good to have to have it consistent with XForms 1.0 where
the first instance replaces the lazy instance.
John Boyer: So the default of default
attribute would be true for the first and false for the rest?
Leigh Klotz: Is there a way to bind to
a second instance in WebFormsaA?
John Boyer: Via the ref attribute with
UI controls. But for a web service, a submission and a request and
response instance. On the xforms-submit handler they'd copy data,
and then on the done, they'd copy it back to SOAP.
Leigh Klotz: For SOAP, yes, but for
REST there's no envelope.
John Boyer: I'd have the submission
bind itself to the instance directly for REST. It would be a lower
probability they'd want to bind UI controls.
Leigh Klotz: For a REST service? I can
see uses of multiple instances on the page.
John Boyer: Yes, one REST service
provides the same data but you could decouple it.
John Boyer: So for the case where
people author multiple instances, what declarations do we want
people to put on every time that says don't generate a default
instance.
Leigh Klotz: So you have to put
default="true" on some instance, and if you don't, then the first
is the default.
John Boyer: To serialize a document on
saving for ODF, for example, you write the content of the generated
instance with default="true".
Leigh Klotz: Why not use the instance
attribute on form and an ID on the innstance?
John Boyer: That's great. I like that
better.
Leigh Klotz: If we go with that, I'm
done.
John Boyer: If we declare a model,
then we go back to model rules.
Leigh Klotz: How do model and form
elements play out against each other>
John Boyer: Who wins?
Leigh Klotz: Yes. We could add an
instance attribute to the model element. That model/@instance sets
the default instance for the model rather than first in document
order. And we copy the instance attribute from the declared form to
the implied model.
John Boyer: That cleans up some stuff
for us. Does anyone object?
Paul Butcher: [Joins]
John Boyer: So unless someone
includes the instance attribute on a form element, they'd get a
default instance. It's only an override of the generated instance
if they put the id of an instance in the form. That replaces the
instance/default.
Paul Butcher: And with a similar
attribute on model in canonical XFOrms.
John Boyer: Exactly. So if you declare
a model for a WebFormsA document, the instance attribute would
override the instance attribute on the form tag itself, should
someone have written it both places. It makes it a clear override
scenario.
Action 2008-11-5.2: John Boyer to add model/@instance to XForms 1.2 and form/@instance to WebFormsA to replace xf:instance/@default.
John Boyer: I'm using the dot
notation here. If you use this in a browser, it will change the
value of a form control. I'm not sure if we'd have difficulty
detecting that.
Mark Birbeck: I sent some comments
this morning and that's one I flagged. In some implementations you
might be able to override the value property but I don't know if
all browsers would support that. So my preference it a setvalue
method. Or you could use a super-element.
document.getRuntimeElementById(x). That would be
feasable.
John Boyer: We might get out of the
gate with that.
Leigh Klotz: But it makes it
non-interoperable with other HTML packages, such as those which do
rich text editing.
John Boyer: Do you hear about it via
value-changed?
Mark Birbeck: In some but not
all.
Paul Butcher: I believe IE doesn't
send the value-changed event.
Mark Birbeck: We're unable to simple
set the value directly; we have to have a method. The other issue
is what browsers to be interoperable with.
Leigh Klotz: Could you replace
document and use a proxy?
Mark Birbeck: You can't set the
prototype of document in IE. AJAX libraries complain about this.
JQuery, for example, doesn't deal with HTML elements. You could do
document.getElementById= but that doesn't work either in IE, I
think.
Leigh Klotz: So we need to be
interoperable with others.
Mark Birbeck: They all have different
ways of doing it. You could offer setvalue and say that .value
works but you need to do refresh yourself. A compromise might be
the kind of code here followed by processor.rebuild(), a procedural
awareness that you need.
John Boyer: Or .refresh().
Mark Birbeck: So they say people like
procedural stuff, and as long as we're able to get at the same data
declaratively or procedurally, as long as it's the same data,
what's the big deal.
John Boyer: Or document.update
Mark Birbeck: Then the document would
need to be intelligent about rebuild vs recalculate.
John Boyer: It could look at the
update flag.
Mark Birbeck: That's a good
compromise. document.update might do nothing. That's good.
Paul Butcher: On the super object that
redirects to model: although that's possible in formsplayer or a
pure script version, you can't do any added value on property sets
because you override. It would have to be done later. If you set
.value then nothing happens. If you set .value=hello, then you've
over-written the value.
Mark Birbeck: In Firefox you can
provide getter and setter methods for properties.
John Boyer: So we are back to
setvalue?
Paul Butcher: Or the author needs to
know to call update after setting a value.
John Boyer: update would not be aware
of the value change though.
Paul Butcher: Yes.
John Boyer: That's a secondary
thing. I'd like there to be a difference between the
schema-compliant date raw value and the formatted textual value
that the form control displays. It would be cool to say
appearance=currency, for example.
Mark Birbeck: We need to know which
value it applies to. In old DOM, it would apply to the pe-value
element. If you're using setvalue, it can apply to the control
itself. It's what we've got in Ubiquity XForms: the method knows to
pass it onto the UI implementation from the control object.
John Boyer: How do we detect that the
UI control has changed when someone types into it?
Mark Birbeck: We register for the
onvaluechanged event. The XForms input control contains a pe-value
control, which contains an input box, and that's three objects. In
the streamlined syntax with an HTML input control, they are the
same object. so the value-changed event gets passed to itself. In
IE you get a value-changed event when the UI changes the value.
Mark Birbeck: [various discussion
about Ubiquity implementation and author expression]
John Boyer: [various discussion about
lexical-presentation filter formatting]
Mark Birbeck: Do you use types or
patterns?
John Boyer: We use both, including
regular expressions. There's also an array of keywords ("currency")
that are shorthands for patterns, including locale.
Mark Birbeck: Filtering in/out is a
few lines of code if we have setvalue. How we expressing it is of
course another matter. I don't think we need any more.
John Boyer: I think we should switch
over to setvalue for FPWD.
John Boyer: We have to run.
Mark Birbeck: I would like to
record that I think the name WebFormsA is the wrong way to go. I
have touched on this point in my email. It's no criticism of the
draft, which is very good. I would focus more on the HTML and XHTML
appearance. The prefixes are making it complicated.
John Boyer: So just get rid of
wfa:?
Mark Birbeck: The example in the email
in RDFa would be for multiple languages and it's great that it's
getting into ODF and SVG but we also conceived it what way but made
the first spec RDFa+HTML. I wonder if we should do the same here.
Get rid of wfa:. Give examples but do HTML first.
John Boyer: Good point.
Mark Birbeck: Focus on the good ideas
from WebForms and HTML5. Talk about an HTML module. Hit those
points.
John Boyer: That would simplify the
document. We'll discuss this next week. I'll come up with another
draft.