Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (Chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Roger Perez, SATEC
Rafael Benito, SATEC
Doug Schepers, W3C
Steven Pemberton, CWI/W3C
Susan Borgrink, Progeny
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers
John Boyer: I need to contact Mark Seaborne from PicoForms to find out the status of their implementation report.
Nick van: [irc] hmm, I have
forgotten to add the actions from last week I guess
Erik Bruchez: Nothing new here,
sorry.
John Boyer: Your topmost action on the
April 2nd list has been done so tell Nick.
Steven Pemberton: My top item is to
sift through the triage and I'm afraid that I didn't get to do that
last week.
Charlie Wiecha: With some help from
you I did task force work. About half of my actions are done. I
still need to update them.
John Boyer: Can you send that note to
Nick this week?
Mark Birbeck: I've got an early
draft that isn't ready for comments yet. I'm trying to demonstrate
how much we can write a self-contained model; there's no XML
Events, for example, so a module would be explained with a bare
minimum of features outside of it. Then the module can be used
outside of XForms. There's no ref or bind, for example, as that
would require the instance module.
Steven Pemberton: The only comment I
had so far is that DOMActivate is sort-of hardwired, and it should
say default instead. We use message for other events that aren't
DOMActivate.
John Boyer: ev:event="load"
Mark Birbeck: This is an assumption I
meant. The load event would fire the activate event the message. To
clear the message, it depends on the type. This is the only way I
could see to define it, but it's a balance. It's specific enough to
use in an AJAX library, but regardless of script or markup, you
need to be able to show with markup and hide with script, or vice
versa, for example. So the interfaces to our objects need to be
defined in terms of other things.
Charlie Wiecha: There might not be DOM
Events.
Steven Pemberton: I like the idea of a
binding that is created when you use it.
Mark Birbeck: The architecture I've
evolved for formsplayer is this: the only way to have
loosely-coupled modules (SilverLight, Flash controls, COM objects,
script) was by making a standard interface between things being
events. You could add a method but you have to have them. So we use
DOM2 events because they can be done. SideWinder uses cross-process
communication with DOM2 events. So we picked this technique. As
long as you can receive the Activate event, any other module can
communicate with you.
Charlie Wiecha: There's two levels of
debate: One is DOM events or not. The second is whether, once you
have DOM events, whether the event is inside the module or
not.
Mark Birbeck: There's a few rules, a
name parameter, ability to pass an object, and hierarchy. I could
have said "banana" instead of DOMActivate.
Charlie Wiecha: There are AJAX
frameworks that just use Java listeners and not
bubble-capture.
John Boyer: This is a great
conversation to continue on the list.
Mark Birbeck: To wrap up, this is the
reason I picked "message," because it's simple and gets to the
heart of these issues immediately.
Charlie Wiecha: This question will
come up in the Backplane right away. I'll take this offlist.
John Boyer: I sent off a message to
Erik. ... and if we extend target to replace all, it might be
reasonable to change to an XPath expression. That was the list in
favor. Erik and Mark wrote back and said that it would cause
confusion and problems with modularization. Erik's email:
http://lists.w3.org/Archives/Public/public-forms/2008Apr/0077.html
and MarkB's email:
http://lists.w3.org/Archives/Public/public-forms/2008Apr/0077.html
Erik Bruchez: I wasn't criticizing
that target doesn't do it's intended function; the main issue is
the name for those with an HTML background, and also it sounds like
targeting a window by name. Let's talk about literals. Name,
serialization, etc. Then if you want literals, you have to double
nested quotes, and heavier for the common use cases. We have good
examples of XPath expressions such as ref.
John Boyer: And target?
Erik Bruchez: For replacing instances
yes. Imagine the HTML target attribute, though. Most of the time
it's a literal _blank or some other constant.
John Boyer: Do you have a suggestion
for an alternative name?
Erik Bruchez: Yes, destination, but I
didn't think very hard about it.
John Boyer: The target in HTML not
being an ID is a counter to anything I've said.
Erik Bruchez: I don't want to hold off
last call.
John Boyer: We could do a contained
last call on the name. Mark?
Mark Birbeck: It's OK to re-use
attributes because you have to come up with names. I think target
is the place you put back where you got. But the target in HTML
modularization is a value of the frame to be written into and that
will cause us problems. I think we need something else for this,
with instances and nodes. Destination is too general. Something
with node only applies when you have instances.
John Boyer: Steven, any one-name
ideas?
Leigh Klotz: I think we should make it
a child element with a ref. The ref makes it clear it's an XPath
binding expression. Like upload.
Nick van: [irc] target-node
John Boyer: How do folks feel about
that?
Mark Birbeck: I thought we'd in
general agreed to have both. An attribute that has a value and a
longhand?
John Boyer: We made the child element
from attributes but not the other way around. There's no input
element on a group.
Charlie Wiecha: [irc] ref would seem
to imply a binding behavior
Charlie Wiecha: [irc] but i guess we
already do that on setvalue
Leigh Klotz: [irc] cf. upload/filename
and upload/mediatype
Mark Birbeck: As XAML does with
either. We're moving towards features of InfoSet rather than
markup.
John Boyer: What about a value
attribute?
Mark Birbeck: So we'd have target/@ref
or target/@value.
John Boyer: If the attribute itself is
already XPath there isn't already a lot of need to drop down to a
child element.
Mark Birbeck: The value of the value
attribute is that you can do concat.
Leigh Klotz: Is this for
replace=instance or replace=all?
Mark Birbeck: I see yes, this isn't
appropriate for replace=instance. It's for
replace=all. For replace=instance value
isn't appropriate, but ref.
Erik Bruchez: I'm more on John's side.
If we have an attribute that's already an XPath expression, Maybe a
completely different type of nested element.
Leigh Klotz: It's all consistent. The
child element content is the same as the submission attribute's
content. If you need the indirection, use the child element's
binding attributes.
Erik Bruchez: The element or attribute
doesn't matter for the name.
Leigh Klotz: It does, because you can
use @ref to indicate that it's a node and not have to call it
target-node.
Erik Bruchez: OK. So just that might
be a reason to have a child element, independent of the reason you
proposed it.
Leigh Klotz: That's the reason I
proposed it. I'm just saying it's OK and consistent to have a child
element with no matching attribute because the constant text
content of the element in this case makes no sense, so there is no
need for a matching attribute?
John Boyer: Are we resolved to take
1.1 to a short LC to rename the functionality currently known as
submission/@target?
Charlie Wiecha: are we sure that a
last call is required?
John Boyer: Steven said last week a
short last call would be required; no CR. We can then go on to PR.
I don't think it will be a big delay.
Leigh Klotz: So then just the issue,
not last call.
Charlie Wiecha: Let's focus on the
issue.
John Boyer: So?
Charlie Wiecha: I'd be in favor of a
change because of the modularization effort.
John Boyer: And Erik's point about no
easy translation of HTML target to XPath.
John Boyer: If there are no objections
then it seems like the proposed resolution is to rename
submission/@target for XForms 1.1. Any objections? More time?
Resolution 2008-04-16.1: We resolve to rename submission/@target for XForms 1.1
John Boyer: Now what do we propose to do from here? There's the child element vs. attribute question, and the name question. Someone should make a proposal.
Leigh Klotz: How about <response
ref=".../>
Nick van: I think it iss a bit
confusing
Nick van: Ok lets keep it target
then
Steven Pemberton: OK, I'll do it.
Action 2008-04-16.1: Steven Pemberton to propose name for submission attribute or child element to replace submssion/@target
Mark Birbeck: Why do we have
instance attribute?
John Boyer: It's a legacy from XForms
1.0.
Leigh Klotz: We had an objection that
it was too late to put it into XForms 1.0 so we had no way to do
it. Then we added instance without the XPath expression. So we have
a set of legacy issues, but clearly this could replace instance
with instance(xyz).
John Boyer: That's true of
submission/@target as well.
Leigh Klotz: Yes.
John Boyer: Should we comment that it should be more explicit about not being for advanced schema use cases such as might be found in XForms?
Leigh Klotz: Yes, they say "state
of the art databinding implementations" but it's really the issue
that we have a conformant XML Schema use. Theirs is more "deponent"
than "state of the art" with regard to XML Schema.
John Boyer: Will you be willing to do
that?
Leigh Klotz: Sure. I'll send it to the
group.
Action 2008-04-16.2: Leigh Klotz to propose a last-call comment to group in response to http://lists.w3.org/Archives/Public/public-forms/2008Apr/0001.html
John Boyer: As our group is on XML
version, the Task Force is a discussion about names and syntax,
modulo the XML/SGML grammar rules. The differences in names are
causing confusions for web authors. If we can come up with an
architecture that allows people to glue their older names (group
and label instead of fieldset and legend, name attribute) then
whatever we do should be applied.
John Boyer: So some of these feel like
custom widgets and some are abstract.
Nick van: And what about "form"? Is
your goal is to have it working in any XForms implementation, or
are we defining how to convert them to XForms controls?
John Boyer: We need to change Core
XForms, such as calculate element of bind.
Nick van: I have nothing against
that.
John Boyer: The claim is that it will
imply a different canonical XForms.
Nick van: The simplified syntax I sent
in the small form could be part of core, but importing "duplicate"
elements that are semantically the same doesn't.
Mark Birbeck: It's tricky. As I said
in the email earlier, we need to mirror HTML. We need to gradually
to map everything to our canonlicalized XForms infoset. There are
many situations where, when generating forms, it's annoying to have
to know the type of a UI control. So having type="range" be the
same as the "range" control would be nice. You find there are lots
of things you might want to preserve. The form element starts to
look like a handy package. But other things we don't want people to
embrace and should be in the XHTML legacy module, so you know it's
not cutting edge and up to date. I worry that as Nick says we
haven't gotten to the root of what we're trying to achieve.
Nick van: I understand why we want
to do it, but if you put the stuff that isn't new functionality in
a separate module, that's ok. But adding it all to the core seems
awkward to me, but I can find it OK if everybody wants it.
John Boyer: I don't find it awkward.
The form element provides functionality we don't have. The edge
case of fieldset and legend is like group with a label. So I have
to support fieldset and legend instead of group and label. It's
just one more set of words to put in. It's not purist or ideal, but
we're trying to rationalize a divergence and converge back. These
pre-existing things weren't bad ideas; we have better ideas now,
but we can support them.
Nick van: It's not hard to support
them. But if you're new you'll get confused.
John Boyer: We're trying to increase
our effective audience for features by aligning with the tag names
they already know.
Mark Birbeck: Yes, that's the
important point. Forms will work with no changes, so the path is
easier.
John Boyer: We define the
mapping.
Nick van: There are a lot of mappings,
and a lot of JavaScript.
John Boyer: We don't want a lot of
rip-and-replace; you can start using Core XForms features in a
fine-grained manner.
Charlie Wiecha: Are they in the XHTML
namespace?
John Boyer: Principle number 12 is
that there should be one namespace.
Erik Bruchez: [leaves]
Nick van: So the core attributes from
the host language will not be available?
John Boyer: They will be
available.
Nick van: So we don't have to mention
them?
John Boyer: No. In my implementation
we use a different strategy than CSS.
Nick van: How about the other inputs?
The host language does the mapping?
John Boyer: The pattern we're looking
for is "input name" and the host language defines "type". So all we
care about is the UI binding. We don't need onblur, etc.
Nick van: submit creates data in HTML
forms.
John Boyer: We need to look at the
mapping systematically. I've articulated the principles.
John Boyer: Let's get an active conversation going.