Alain Couthures, AgenceXML
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennel, MarkLogic
Steven Pemberton, CWI/W3C
John Boyer, IBM
Kurt Cagle, LOC
Dan McCreary, Dan McCreary & Associates [Joined Late]
Steven Pemberton: I've worked on
the out-of-date actions. John's action item is not confused
anymore.
John Boyer: I deleted or closed
duplicates.
Leigh Klotz: It's semi-official
policy that they're doing a rolling-release.
Steven Pemberton: I don't think we
need to do anything about this.
XForms 1.1 load erratum Awaiting move to XForms 1.1 wikispec erratum http://lists.w3.org/Archives/Public/www-forms-editor/2010Nov/0000.html
Steven Pemberton: They're fixed in
the 1.1 Wiki version.
John Boyer: For the first it's in the
errata. I'll check the second.
John Boyer: Both are done.
Steven Pemberton: Leigh, any
comments?
Leigh Klotz: Maybe Erik will say
something when he joins.
Steven Pemberton: Should I raise this
at HCG?
Leigh Klotz: When Erik joins we can
come to consensus, and then I think that would be
appropriate.
Kurt Cagle: With the move away from
namespaces, is it worth talking about the dual-path effort?
Steven Pemberton: It might well be
worth suggesting. It should be clear that we're asking for a
namespaced version.
Erik Bruchez: [joins]
Kurt Cagle: HTBL
Leigh Klotz: I suggested WebBL to Art
Barstow.
Kurt Cagle: I've talked to Sam Ruby
about joining the WG. Maintaining parallel tracks may be
important.
Steven Pemberton: The more we talk
about this, I think we should surface it at the HCG for a future
agenda item. That may lead to inviting others.
Leigh Klotz: Parallel development may
lead to too much and too little overlap. I'd like to see XBL in the
desktop browser for the implementation (like Mozilla XForms and
Ubiquity) and then a namespace addition for use with our own
implementation on top of that for macros.
Kurt Cagle: I don't see any reason not to go down that path. There are some implementations that already do that. Separating the labels out seems obvious in retrospect. Does it break the model in any way? I haven't seen anything that would.
Leigh Klotz: What about a label
outside a repeat? Maybe we just don't allow it.
Nick van: It's quite natural to put
labels outside a repeat.
Leigh Klotz: So perhaps the label is
relevant if any of the matched controls are relevant.
Erik Bruchez: Maybe you can have them
always relevant.
Kurt Cagle: If there's no data it
wouldn't display.
Nick van: If you take the label out of
the input, and put the input inside the table, and the label
outside, how do you make the table non-relevant? Wouldn't part be
non-relevant?
Leigh Klotz: It would be the column
non-relevant.
Erik Bruchez: I could see it either
way: relevance is tied to the list of concrete controls, and the
table scenario is almost screaming for some way. (Empty table with
headers, or no data - no table). If you have labels relevant when
there are no concrete controls, it's a scenario we don't have in
XForms 1.1. By nesting we get non-relevance of labels, but this
would be the first time we have something that's separate from the
related control.
Leigh Klotz: We could put ref on the
label to bind to the data.
John Boyer: Label is part of a
metadata cluster, and isn't independently existing. Relevance
doesn't apply to label, help, hint, alert. So I think that the only
way that label gets its permission to be seen or not is through the
form control it's associated with. The repeat has an interesting
case because we're saying we'd like to overlay the labels of the
repeat as a column header. There's a point where we need a form
control.
Kurt Cagle: I've thought that for a
while.
Erik Bruchez: We call that L/H/H/A.
That's true in the current spec, but when we implement label
separate from controls, we allow them anywhere (before or after the
control). Labels can be in non-relevant controls while the control
is outside the group, so it's not just a property or associated
data for the control. As soon as you have to implement that as a
separate entity, you have to break some of those assumptions. I'm
not sure it's blocking us from saying how labels pointing inside
repeats behave.
John Boyer: So at toplevel, make it a
form control?
Erik Bruchez: When you implement it
you kind of have to look at it that way.
John Boyer: So we're saying it
duck-types to a form control. If relevance applies to it, all the
things that apply to other form controls, it's not different from
an output, but it's also a label for something else, for
screenreaders.
Kurt Cagle: A label would have a for
attribute.
Steven Pemberton: Listening to this,
I've got some slight misgivings. First, this is the first time
we've made a decision about a forms document for presentational
reasons. It's because the styling languages we have available, at
least CSS, don't let us style the way we want to. We want to
position a label elsewhere and we want to mess around with the
document structure so the document looks a bit better. First that
gives me misgivings because you can style for different modes and
devices; we've seen some very good examples of that, for example a
speech interface, with exactly the same form. So I'd like to
address the use-case instead of the solution. I understand that
label/@for in HTML does presentation in the document, even though
strictly speaking that's not one of our aims. I'd much rather try
to find what we're trying to do in a more presentation-oriented
way.
Erik Bruchez: That's very
idealistic.
Steven Pemberton: Sure it is, but that
doesn't mean we can't try and do it.
Erik Bruchez: This is an obvious
solution, though there may be others. We have markup on the page.
CSS can move things around a little bit. With XSLT in 1998-1999,
that was going to be the web styling language, then it became split
into two very different things. XSLT lets you shuffle elements.
With CSS we don't have the capability to shuffle elements on a page
in a way that's as flexible as that. In our implementation, this
was one of our first extensions, because we couldn't see how to
solve the problem in another way. I'm a little skeptical.
John Boyer: We have a great ideal, but
also a practical problem in terms of how people are designing
forms, whether we like it or not. Because they don't have the
mechanisms the way they need from us, they leave the input/label
blank and then use output/label to position the labels where they
want them.
Steven Pemberton: I quite understand
that there's a use case. I'm not saying we shouldn't search for a
solution, and this HTML solution is an obvious one. But if we had
one that's more xforms-like, I'd have less misgivings.
John Boyer: From an A11Y standpoint
it's a really bad idea that the label is blank. We're trying to fix
that. Our design environment adds styling of the label to suppress
it, then creates a second label, and points to the other label. So
rather than having a label that says I'm for something else, we
have the dependency going somewhere else.
Steven Pemberton: Yep.
John Boyer: An output which gets its
content from the presentation layer.
Kurt Cagle: I've been putting together
an XForms-esque application for internal use. One problem I run
into with form controls is that there are two fundamental
structures I run into: tables and property sheets. Property sheets
are lists of items, atomic values in most cases. The challenge I
have with labels in the form component is that, even from CSS, it's
remarkably difficult to do something that should be easy. You can
do funky things with floats. It's non trivial. On the second
point...
John Boyer: Let's consider the first
point. Instead of label/@for, use an output as a column header with
value from an XForms label element in a form control in the repeat,
the output is a separate form control whose relevance is governed
by different rules and whose value comes from another place in the
document. Then inside the repeat, the form control's labels should
be hidden from view.
Kurt Cagle: I don't see it as a bad
solution, but it has problems. First you are binding a control to a
label, and this would go back to the control having a value
separate from the model. It sets an interesting precedent.
John Boyer: You already have it with
label with static content.
Erik Bruchez: And output that has a
value.
Kurt Cagle: Also, it may end up
introducing a level of complexity; the more you have to
de-reference the more you have teach complexity. If you have
outputs that reference label values, that's another point you have
to teach. I'm not saying it's bad (structurally it's elegant), but
for users it's an eyebrow-raiser.
Steven Pemberton: Who just joined?
Dan McCreary: I am a big XForms
advocate and I have a few wikibooks out there.
Steven Pemberton: And you coined the
term XRX?
Dan McCreary: Yes.
Steven Pemberton: We're glad you could
join us.
Kurt Cagle: This is sufficiently
pressing that we should document the approaches. If we can make the
arguments pro and con and look that would be good. I'd be willing
to do that.
Steven Pemberton: I'd like to ask
people to document the use cases. The only real place where I come
against it is with repeats. If there are other obvious use
cases...
Erik Bruchez: In our implementation,
we don't handle the repeat as the use case has been presented; they
must be in the same repeated container. I find the idea as Kurt
mentioned of dealing with repeats something to consider. The most
pressing issue is layout; repeat is a second one.
Steven Pemberton: You're saying that
there are use cases different from repeat, examples you can't do.
I've personally never had that problem. I'd like to know about them
to so I can use that to evaluate potential solutions. Just send
them in.
Kurt Cagle: Where do we write this up?
1.2?
Leigh Klotz: Or just start as
email.
Action 2011-01-26.1: Kurt Cagle to write use cases and pro and con of various approaches for separate label binding.
Action 2011-01-26.2: Erik Bruchez to write use cases for non-repeat separate label binding.
Nick van: Betterforms is Lars and
Joern.
Leigh Klotz: Are they doing the same
as Erik's AVT?
Nick van: They are.
Steven Pemberton: Could you do
it?
Alain Couthures: It's not that easy
because binding are attached to elements, not attributes.
Steven Pemberton: I could imagine some
level problems with XSLT.
Alain Couthures: It's not.
Nick van: I also have XSLT that
generates an XForms document, but double curly brackets are XForms
time and single are XSLT time.
Dan McCreary: I use the same
thing.
Steven Pemberton: If I were using
Alain's implementation I wouldn't be using XSLT. Leigh. Yes, your
document is the input document.
Steven Pemberton: We could all look at
this.
Leigh Klotz: This may provide a second
implementation of many XForms 1.2 features we could fast-track onto
the Wiki.
John Boyer: If we have AVT in
controls people may try to do this in other places like nodeset or
calculate.
Nick van: These are on host-language
attributes such as class.
John Boyer: How do we have that
available in XForms? We could suggest it.
Erik Bruchez: There's enough interest
but not in the XForms spec. Quite a few implementations do HTML and
we could have that.
John Boyer: We have CSS
pseudo-elements and pseudo-classes so there is a place. There are
real challenges in doing AVT in XForms. If we're talking about host
languages, that surely makes things a lot easier. The circular
referencing potential and data lifecycle problems don't
occur.
Erik Bruchez: I don't agree it's
challenging. Everywhere we have a static value that's not an XPath
expression or ID, you can put an AVT. I don't see any problem in
our implementation.
John Boyer: It may be that you're not
doing a recalculation engine, such as calculate or relevant.
Erik Bruchez: Right. The use case for
AVTs provides a solution for dynamic values where previously you
couldn't have one. So we don't do it where there are XPath
expressions (ref, nodeset, value, context, etc). Where you need an
AVT is for submission/@action, headers, etc. We have an exhaustive
list. If you limit the use of AVT to those sets, you can, in one
sentence, say wherever there is a static value you can use an
AVT.
John Boyer: There's a teachability
issue; there are places where you can't use an AVT.
Erik Bruchez: If you try to use an AVT
to produce an XPath expression you're already in trouble. It's
doable, but the main use case for AVT outside the host language is
to make the language lighter than we did in XForms 1.1 with child
elements. The world wants more short syntax and we have to be, as a
WG, aware of that. Anything we can do is good.
Nick van: It makes the code more
readable, eliminating child, concat, quotes, escaped, etc. It gets
messy. AVT makes life easier.
John Boyer: I don't know why it's any
different in the child element vs. the avt.
Nick van: You have to use static and
dynamic parts and concat. For every change you need quotes. It gets
complicated.
John Boyer: OK, that makes sense.
Steven Pemberton: As for your
control over the host language issue, I've been thinking of another
heresy where we can have XForms documents without switching
namespaces. We could provide a ready host language for the case of
very many simple documents we already have.
Nick van: What's the advantage over
XHTML?
Steven Pemberton: Maybe we're ok, but
maybe it's a heresy.
Leigh Klotz: I think we already have a
host language, XHTML+XForms, and we're slated to write it up. If we
want to put in AVT as an optional feature there then we
should.
Kurt Cagle: It would be difficult to
do something that isn't XHTML. Maybe we could move namespaces. In
order to be able to stay on the parallel track, we have to move
with the language. Those namespaces may have to get incorporated
back into the XHTML namespace.
Leigh Klotz: Kurt do you think they're
going to eliminate XSLT support?
Kurt Cagle: Michael Kay is pushing to
make sure they don't.
Leigh Klotz: I see XSLT PI, XBL PI,
for macros, then namespaces disappear and it turns into browser DOM
HTML or XHTML, and in-browser XBL works there.
John Boyer: That puts us out of range
of mobile phones.
Leigh Klotz: Mobile phones have 1GHz
processors. And remember we dillied about XPath because the mobile
phone members said they'd never do IEEE floating point, and then
Java ME came along and they all did it.
Steven Pemberton: Let's stop
there.
Steven Pemberton: Next week, XPath
2.0?
John Boyer: I won't be here.