W3C Forms teleconference April 16, 2008

* Present

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

* Agenda


* Previous Minutes


* XForms Basic.

John Boyer: I need to contact Mark Seaborne from PicoForms to find out the status of their implementation report.

* Action Item List


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.

* Thread for "Unfortunate name choice for target attribute"

http://lists.w3.org/Archives/Public/public-forms/2008Apr/0075.html http://www.w3.org/2008/04/09-forms-minutes.html#item03 http://lists.w3.org/Archives/Public/public-forms/2008Apr/0052.html

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.

* Basic XML Schema Patterns for Databinding version 1.0 Last Call Apr 30


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

* Forms Task Force


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.

* IRC Log


* Meeting Ends