Steven Pemberton, CWI/W3C (chair)
Uli Lissé, Dreamlabs
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox (minutes)
John Boyer, IBM
Erik Bruchez, Orbeon
2010-01-13 http://lists.w3.org/Archives/Public/public-forms/2010Jan/0017.html
Steven Pemberton: I haven't heard any news. They are meeting now.
Leigh Klotz: Should we just put them on the news page at the same time as posting them on the list?
Action 2010-02-3.1: Steven Pemberton to publish news items such as new implementations or users of XForms both as mailing list notes and home-page "news" entries on an ongoing basis.
Steven Pemberton: This got discussed at the most recent HCG. The discussion would have gone on longer, but we ran out of time. There were no conclusions, and that's why we have this message minuting some of the dicsussion. The next HCG meeting is on a special topic, so I hope it will be raised at the next after that.
Erik Bruchez: I'm not sure I
understand; the email says that it's been deprecated in the current
draft, but you're saying that's not final?
Steven Pemberton: Yes, it's not even
last call yet; this is a heads-up. It's WebApps. Before DOM,
"click" was the event used for activation, but the name was
misleading and browsers implemented it non-interoperably, so you
couldn't distinguish between "enter in input." So now they claim
that "click" is interoperable and is as if it were DOMActivate, so
return gives you a click.
Erik Bruchez: They say they're not
equivalent.
"While DOMActivate and click are not completely equivalent, implemented behavior for the clickevent type has developed to encompass the most critical accessibility aspects for which the DOMActivateevent type was designed, and is more widely implemented. Authors are encouraged to use the clickevent type rather than the related mousedown or mouseupevent type to ensure maximum accessibility."
Steven Pemberton: A good
discussion. From what I understand, I think we don't object to this
change, even if we don't like it.
John Boyer: Sounds good.
John Boyer: Lately we have been
ending at the top of the our. Should we do that?
Steven Pemberton: Yes. It's hard for
me anyway.
John Boyer: That's an agenda
change.
Resolution 2010-02-3.1: We change our call ending time to 1700z.
Leigh Klotz: By the way, I won't be here next week.
Steven Pemberton: Erik has stepped
out. John, is there a partial XBL2 implementation in
Ubiquity?
John Boyer: It may be in the WebKit
implementation, but I don't know for sure.
Steven Pemberton: We should ask Mark
Birbeck.
Leigh Klotz: http://xtech06.usefulinc.com/schedule/paper/137
is Mark's XTech paper on using XForms, SVG and XBL2.
Leigh Klotz: http://code.google.com/p/xbl/
is a JavaScript implementation of XBL2.
Nick van: The Mozilla note said it was
slow.
Erik Bruchez: [returns]
Leigh Klotz: Erik, are you using XBL2
with XForms now?
Erik Bruchez: As far as spec
compliance, it's another question. We try to implement whatever we
find useful for our purpose. It's too early to call it an XBL2
implementation. We might be able to say we implement a
subset.
Leigh Klotz: I think we need to move
something forward.
Erik Bruchez: It might not be perfect,
but it has even more value if implemented in browsers. If nobody is
implementing XBL2 for the purpose of components in XForms, then it
means we have an opportunity to do something better and steer it
better in a direction.
Leigh Klotz: For XForms components
would you start with XBL2 as a base or start with a blank
document?
Erik Bruchez: Good question. I think
resource binding to elements, resources, registering handlers, etc.
is all good. While implementing our components, we found this was
all on the right track in XBL2. That's a large part of XBL2. The
templating part as well; it's a mini-XSLT underneath, though I
don't know how I feel about the pseudo/limited aspect. I think the
idea is a good one. I think some thinking is needed on our side,
having implemented components, on XPath-specific features. For
example single-node binding controls and XPath context, itemset,
etc. XBL2 doesn't help with that. So one question is whether we
would need modify XBL2 to have hooks, or can it be in XForms.
Something has to address it.
Leigh Klotz: Should we attempt to move
it on to the next stage?
Erik Bruchez: Of course, we'd need an
editor. But then do we want to base things on XBL2?
Leigh Klotz: It would be good to be
thinking about it now.
John Boyer: Why do we need it?
Leigh Klotz: We need to decide for
XForms 2.0 whether to use XBL2 or not. If we use XBL2 then we need
to get it to move forward; if not, we need to start afresh.
Erik Bruchez:
http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components-guide#TOC-Level-of-support
Erik Bruchez: It might be too early to
say we don't want it. We maybe can't focus on it now with limited
resources. It's a lot of work though. It would require F2F, several
interested people, etc. We can provide some input to a
discussion.
Leigh Klotz: Do you think you could
identify other communities or WGs that use XBL and might be
interested in moving forward?
Erik Bruchez: XBL is very XML
oriented. It has an XML transformation language, etc. I would
imagine it would appeal to XML technology rather than HTML5 people.
I don't think it solves any problem for the Transformations
group.
Steven Pemberton: In your XBL, are the
selectors XPath or CSS?
Erik Bruchez: We implement a subset of
CSS, but underlying that is an XPath expression and you can put in
an XPath expression; we do translate simple CSS expressions. XPath
does more than CSS. Whichever way you go, you can achieve your goal
of identifying elements to which bindings apply. The template
language is weak; they use CSS to determine elements to copy from
source to shadow; but it's a limited language because they use CSS.
CSS doesn't allow you to select attributes; they invented a syntax
for accessing attributes of bound nodes. We had to work around that
and provide extensions. The use cases were not sufficient.
Steven Pemberton: Here is another Javascript XBL2: http://www.amplesdk.com/about/technologies/
Steven Pemberton: For technical
talk, I have some opinions. I was one of the co-designers for CSS1
and it was a different set of requirements that XBL. I think, for
that reason, you are bound to come across such problems. The CSS
selectors just don't do the job.
Erik Bruchez: As far as XBL2 is
concerned, it similar to mapping bindings to node. If you give that
CSS is OK for identifying elements for styling, it's OK for binding
XBL. But where it doesn't work well is in the template language;
it's a stretch there. That's a weakness of the design; it works in
a number of use cases, but you quickly reach limits. So you would
have CSS for binding and XPath for transformation.
Steven Pemberton: CSS was designed
left-to-right; you can't select a preceding element.
Erik Bruchez: If you are a browser
vendor you are going to use CSS as it's already there. For a
server-side implementation that you control entirely, you can use
XPath.
Steven Pemberton: We've reached the
top of the hour. So let's wrap this up. I thin Leigh is saying that
we should keep ourselves open on this because it's a co-technology
to XForms; we've used it quite a lot and it would be useful to have
as a standard, but Erik is saying we don't have the cycles. Is that
a good summary?
Erik Bruchez: With my record for
action items, it's hard to say I can spend a lot of time on it. As
for implementation, we have tremendous interest, but it's another
question to say we are going to take over XBL2 and coordinate with
third parties. But clearly if the group is going to be serious
about components, we need to look at it and think about our
components. The question is can we do it now?
Leigh Klotz: I can see a future in
which everything that Erik says about XBL2 and XForms gets fixed, a
spec magically gets published, and others use it. I can also see a
future in which nothing gets done, and nobody uses XBL. So I think
we should continue to discuss.
Steven Pemberton: So resolved.
Resolution 2010-02-3.2: We continue to discuss XBL2 and XForms.
Steven Pemberton: We will ask Charlie Wiecha to take minutes next week, in Leigh's absence.