Alain Couthuries, AgenceXML
Steven Pemberton, CWI/W3C (chair)
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
John Boyer, IBM
Erik Bruchez, Orbeon
Kurt Cagle, XMLToday
Steven Pemberton: Nick can't travel
after June and that pushes us into May but it's already blocked
off. Unless we ask Nick to join remotely.
John Boyer: I will have a difficult
time getting travel approval.
Steven Pemberton: So this may be a
virtual meeting. As long as people turn up.
John Boyer: We've gotten decent work
done.
Steven Pemberton: We could meet, work
on action items, and then come back.
Steven Pemberton: So we need a date and I'll do a questionnaire.
ACTION-1783 Steven Pemberton to send questionnaire for next virtual F2F date.
Leigh Klotz: We should move this list to a wiki page. http://www.w3.org/MarkUp/Forms/wiki/FtF_2011_Virtual_1_Agenda
Steven Pemberton: WebApps is
willing to let go of XBL and wants to know if we want to take it
on. It gives us the power to do what we want, such as use XPath
selectors.
Leigh Klotz: Is the browser-vendor
work going forward?
Steven Pemberton: We didn't dicsuss
ut.
Kurt Cagle: They appear to have backed
away from the shadow-DOM work. It didn't fit from their standpoint.
They're going so many directions right now and it's low on their
priority stack. There's been some experimentation but it's nowhere
near close, except Dimitry Glazkov's component architecture. It's
the second candidate for a behavior specification. There's no spec
at all.
Steven Pemberton: I'd be interested to
know what others think. Is this horrifying, interesting,
brilliant?
Kurt Cagle: I think it's something we
should probably be doing. There are significant advantages to being
able to have the specification here. There are implementations out
there with a basis other than HTML makes sense, but to do that we
have to have an underlying behavior specification for binding it
on. An HTML version with that simply won't happen. Cameron
McCormack said he hoped to see SVG with an XBL-type behavior
independent of XForms. Realistically I think it's either us or SVG,
but I don't think it's for them now. Realistically it's closer to
Forms WG.
Steven Pemberton: And you're willing
to put some cycles into it.
Kurt Cagle: Yes, absolutely.
Steven Pemberton: John, do you have
XBL?
John Boyer: There is some XBL-like
stuff in Ubiquity that Mark was working but we haven't heard from
him on it.
Steven Pemberton: I understand he's
become CTO of a startup.
Steven Pemberton: What do you think
about XBL?
John Boyer: I can't help but think
it's not great news. It's another fairly large and complicated spec
to take on ourselves. It's an uphill battle. I think it's a
powerful paradigm but it's not going to appeal to garden-variety
authors. It's more about implementors.
Steven Pemberton: Erik?
Erik Bruchez: As usual, I agree with
John on the fact that the work if we take over is quite
significant. In our implementation, lots of users find the XBL
component support one of the best aspects of it. So it is something
that has a lot of value for implementors and for those who need to
develop their own controls in XForms. So the whole concept of being
able to define components and bring them to life in an XForms or
XForms-like context has a lot of value. It goes way beyond XForms
and dates back to Mozilla. Although XBL2 has kind of died, a lot of
people see value in the concept. One reason we'd started looking at
components in the WG is, let's say you've never heard of XForms and
you look at the specification and see what you have in XForms, it's
very limited. The controls are very basic. HTML forms are likely to
add more controls and basic widgets, but that's a basic set.
Nowadays frameworks like Dojo and YUI have much richer sets of
widgets. There's a temptation to look at XForms like another
framework and see nothing appealing about widgets or building
advanced controls. So that's one of the erasons why as a WG we
started looking at that; there's a real need for more controls. In
our implementation experience, it's been one of the best things
we've been working on in our own product. I'm a little torn: on one
hand it's a clear use case and the requirements are clear, and what
we want to achieve is clear. But on the other hand, the amount of
work to bring that to a specification is daunting. If we're talking
about cutting down XBL2 to what we've implemented is quite a lot of
work. You'd have to go through every single line of the spec to
check, or ask if it should be implemented as well. Even without
adding new stuff that would specifically help XForms, it's a lot of
work. Especially since as the Forms WG we need to come out with
XForms 1.2 and that's going very, very slowly. There's been some
progress but we still have a big push needed to get even to a first
draft. If Kurt has resources to work on it, maybe that changes
things a little but, but there would still be an impact on other
group members to erview, comment, and discuss.
Steven Pemberton: Anyone else?
Leigh Klotz: I'd like to know where
Dimitry Glazkov's is going and what the WebApps and HTML5 people
are going and not go another direction. Also I think we should let
Kurt work on this but with a date that doesn't interfere with
XForms 1.2.
Erik Bruchez: I'd also like to know if
the Google folks who were interested in this a f ew weeks age are
still going forward.
Kurt Cagle: They said a lot of the
Chrome engineers who have looked at XBL have no interest in
pursuing it. If they're doing some other related architecture it
would be worthwhile ask. We should have a certain degree of
assurance that our work is not for nought.
Steven Pemberton: Art's Poll:
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0874.html
Erik Bruchez: Ian said he expects
Dimitry's work to be eventually in the HTML5 spec. So major aspects
of XBL folded into HTML5.
Kurt Cagle: I didn't see that, but I'd
have to go read it again.
Erik Bruchez: They like the use cases.
It will be useful to us only if and when they implement it and have
some first draft of spec.
Leigh Klotz: I think XForms as a
declarative, markup interface to native facilities is a good story:
submission for XHR, XML Events for DOM Events. It would be good to
have some flexibility to change what our component architecture
would be if HTML5 provides something underlying using color-coded
squiggly braces we can still markup-wrap it but it may
change.
John Boyer: I put components lower on
the priority list than some existing XForms 1.2 work that we need
done for our implementation.
Leigh Klotz: I think components is
blocking some XForms 1.2 work and we should have at least a
story.
Kurt Cagle: I agree with Leigh; I
would start with a new requirements document. XBL2 was overtaken by
other developments: it's a pre-AJAX spec that's now orphaned. There
are a lot of things we need to look at in new use cases:
server-side components, web events, whither JavaScript, etc. It
would be worth the effort to put together a requirements document
and then see if it's worth pursuing.
Erik Bruchez: We shouldn't give on
this, completely. It's a burning need for me, but there are other
things that need to get done. We can't come out with a component
architecture and not finish XForms 1.2. I also feel that Mozilla
has limited resources and must work hard to keep the browser alive
from competition, and I don't think it's a lack of use cases. Once
they get hardware acceleration etc. out, things like a component
model will come back in the next year or two. So I think we should
keep that in mind and write something more solid on the WG Wiki as
a requirement document as Kurt's suggest, and clarify our vision of
what we need. I can contribute to that in a limited way and
definitely participate, a few days of work to frame what we need.
Taking over the specification would be a full time job. We can
start small and see where that takes us.
Kurt Cagle: I think it would probably
be good to talk. My recommendation is that we go back to WebApps
and say we're interested in taking on the spec but for homework we
need to resolve what "forward" means before we commit.
Steven Pemberton: We also might not
have the two implementations.
Kurt Cagle: There's only one XBL2
implementation and it's unsupported. We need to ensure there are a
couple of working ones. Having said that, I may be in a position
(indirectly) to be working on a component architecture. There are
significant advantages to marrying a client/server component model
with an XML database. So that might jump-start some
implementations.
Steven Pemberton: What are our next
steps? It sounds like we can give this to you to lead, Kurt?
Kurt Cagle: Definitely.
Steven Pemberton: So our response at
the moment is that we want to investigate the possibilities, but we
have some worries about being able to find enough time and
implementations to conform to the spec. We're currently
investigating how we want to do.
Leigh Klotz: And we don't want to
proceed in isolation of component work going on in Webapps.
Kurt Cagle: I agree.
ACTION-1784 Kurt Cagle to provide proposals for XBL requirements and use cases.
Steven Pemberton: As I remember, we
decided to take out some bits from the current algorithm and say
what should happen rather than now.
John Boyer: I think I have an action
item to come back to the group with something. There's nothing
further to discuss.
Steven Pemberton: So we're waiting on
a proposal for interoperability without being to specific about how
the implementation should work, a new description.
John Boyer: Right. It's overdue right
now.
Kurt Cagle: I am working on a proposal for early next week.
Steven Pemberton: Awaiting XML
Prague publication of paper by Alain Couthures.
Alain Couthuries: Publication is next
week.
Kurt Cagle: Norm Walsh sent out a note saying they would meet only as needed now.
Leigh Klotz: We discussed this and
decided not to do it, but now two implementations (betterForm and
XSLTForms have done it).
Steven Pemberton: How have they done
it?
Leigh Klotz: @incremental in ms.
Erik Bruchez: Do you feel it needs to
be done by the author on a per-control basis? What if you want all
to have the same delay? (We have an application setting.)
Leigh Klotz: I brought it up but the
group said it would be better to do the something adaptive.
Erik Bruchez: It's not how I'd expect
the feature to work that 17 characters producing 17 server round
trip. We should clarify that incremental doesn't mean every
keystroke sends an event.
Steven Pemberton: Alain?
Alain Couthuries: Using the JSON API
with wikipedia it's too slow. The responses came back slowly. It
was better to wait for 4-5 keys. It was a nice way to describe it.
The submission is to an external server.
Leigh Klotz: When I proposed this
before that's what we discussed but the group decided that the
application should decide how frequently based on load.
Kurt Cagle: Maybe we should re-address
the issue. I can see an argument for saying you don't want a
response until the typing is done. I think it's an author
decision.
Erik Bruchez: Recap: Maybe I'm wrong
but it's clear to me that the specification doesn't require an
event for every keystroke: you don't have to tab out. For us, you
need two delays: (1) while the user is typing you get an event
every 1-2 seconds and (2) if you type quickly and stop typing,
dispatch an event. You notify the application regularly. If you
want keystroke you should listen for keydown events. Given this,
I'm wondering what @delay would do. It might go too far. I don't
see the need for delay preventing dispatching every
keystroke.
Kurt Cagle: I don't necessarily see it
tied to a key event. Let me give you some thinking from a database
standpoint: chances are I'm going to want to make sure before I
send information back that I have enough query characters to
download a bunch. So if I query and get all a back,
that's a fairly general query. If I have a minimum of a name, you
would use delay as an optional field to let the user type enough
info and trigger only upon receipt of a decent key. Whereas if you
don't have something like that it's going to vary by implementation
as to when the trigger is.
Steven Pemberton: It sounds like we're
not yet finished with this topic but our time is up. We'll have to
put this off for another time.