W3C Forms teleconference September 23, 2009

* Present

Kenneth Sklander, PicoForms
Steven Pemberton, CWI/W3C
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Uli Lissé (DreamLabs)
Nick van den Bleeken, Inventive Designers
Charlie Wiecha, IBM [joined late]

* Agenda


* Previous Minutes

* PicoForms

Steven Pemberton: PicoForms implemented InputMode.
Nick van den Bleeken: [irc] and about JSON submission.
Steven Pemberton: The new widget screenshots.
Kenneth Sklander: http://picoforms.com/picowidgetsolution/screenshots

* inputMode

John Boyer: Are you using inputMode?
Kenneth Sklander: We had it but changed to match the XHTML spec
Steven Pemberton: [irc] XHTML Basic 1.1
John Boyer: We have no conformance tests defined. If we had some tests we could make this an optional feature.
Kenneth Sklander: OK

Action 2009-09-23.1: Kenneth Sklander to send to list suggestions for inputMode tests.

* JSON Submission

Steven Pemberton: We'd like to use your experience, Kenneth.
Kenneth Sklander: When we receive JSON data we transform it to JSON. It is transformed back to submit. There are some issues in the mapping (arrays, etc.).
John Boyer: Are there issues from XML to JSON?
Kenneth Sklander: Most JSON to XML converters are object/name/value. The XML data is then inconvenient. We map to a tree structure, but 90%. The fully-addressable version isn't very convenient or useful because the XPath is awkward: object[1]/object[name="test"][1] but the convenient method is test[1]
Leigh Klotz: It sounds like it's like using a DOM API and losing the power of XPath.
John Boyer: Do you have a document about the translation?
Kenneth Sklander: Yes. You get the same data but not the same representation.
John Boyer: Do you have documentation?
Kenneth Sklander: Yes.
John Boyer: Charlie is going to write something up. Can you provide some information?
Kenneth Sklander: Yes, I can paste it in from our internal site.

Action 2009-09-23.2: Kenneth Sklander to send to list information about lossy-but-convenient JSON-to-XML transformation.

* Rechartering

Steven Pemberton: We have to say what we're doing by the next AC meeting. The required points that published a new recommendation and are rechartering.
John Boyer: Here's the statement for the last one: http://www.w3.org/2002/Forms/Activity.html
Steven Pemberton: And we should say that we are making XForms 1.1 Basic a profile of XForms 1.1.
Leigh Klotz: Do we need to issue XForms 1.0 Basic as a Note before the AC meeting?
Steven Pemberton: No.
John Boyer: And FPWD of XForms for HTML.
Steven Pemberton: Is that 1.2?
John Boyer: It's half of 1.2. We are continuing on the other half.
Charlie Wiecha: [joins]
John Boyer: And FPWD of XForms 1.2.

* DOM Events 3


Steven Pemberton: We missed a message from Doug Scheppers, about deprecating some of the events we use in XForms. Mark Birbeck replied saying it was a bad idea.
Charlie Wiecha: I thought we discussed this.
Steven Pemberton: Namespaces last week, but not the deprecation.
Nick van den Bleeken: We discussed it in July but I can't see who got the action item to reply. It's not in the list.
Nick van den Bleeken: http://lists.w3.org/Archives/Public/public-forms/2009Jul/att-0045/2009-07-29.html#topic5
John Boyer: So we may have to fabricate these events, as we do now.
Nick van den Bleeken: That's a performance issue.

John Boyer: What's the question?
Steven Pemberton: As I understand it, they're deprecating these because the mainline browsers don't implement them.
John Boyer: Is the deprecation because HTML5 has new events?
Steven Pemberton: Doug Scheppers said they wanted a documented that listed only what all five big web browsers use.
Charlie Wiecha: The DOM is also used server side. XML Pipeline may want focus, but not click.
Steven Pemberton: It's mostly focus in and focus out, not activate.
Charlie Wiecha: Aren't there differences in timing and bubble behaviors?
Nick van den Bleeken: They aren't the same. Some don't implement bubble.
Steven Pemberton: Anne von Kesteren said that all events should be application-specific. That then gives you three different submit events, which is a problem in a mixed-namespace document.

Nick van den Bleeken: I responded in July to this email.
John Boyer: What's the next step? I hear the issue is a duplication.
Steven Pemberton: focus, blur; they have a different order.
Nick van den Bleeken: focusin doesn't bubble. DOMFocusIn bubbles.
John Boyer: full capture/bubble?
Nick van den Bleeken: Yes.

Leigh Klotz: It looks like DOMFocusIn applies to any target but focus applies only to HTML forms elements: http://en.wikipedia.org/wiki/DOM_Events#Common.2FW3C_events and http://en.wikipedia.org/wiki/DOM_Events#Common.2FW3C_events
Kenneth Sklander: That is correct.
Steven Pemberton: So they might ask us to to add the event to our spec.
Charlie Wiecha: But DOM is a core technology, server-side as well.
Steven Pemberton: Good point.

John Boyer: So we care about the general applicability of the event.
Nick van den Bleeken: But focus can be sent to all elements, if I read the spec. All UI elements. There is text in DOMFocusIn saying the event is deprecated, and changes between DOMLevel2 and DOMLevel3 say focus and blur are now added to the UI module. So it's not just the form elements.
John Boyer: So if we base a new XML Events on a new DOM Level 3 events, that would be a new version of XForms. So some translation may be necessary. Is that a problem for other than just the name change?
Steven Pemberton: There's backward compatibility. The backplane approach would provide common events. The "wheel" and "click" events are hardware-specific; it binds you to a specific hardware. So DOM 3 Events would make the DI problem worse.
Steven Pemberton: So should these be centralized or done by each application? We'd prefer to see centralized so that things can be combined, but HTML5 is a monolith.
Nick van den Bleeken: [irc] I personally think the UI events should be defined in a separate UI spec, because the UI events won't occur on my data DOM, but they shouldn't be defined in HTML5, then I prefer DOM Level 3 events
Charlie Wiecha: That's the point about DOM being more generic, as there is server-side technology.
Leigh Klotz: So we should follow Anne von Kesteren's suggestion and ask that all UI events be removed from DOM Level 3 and they publish a separate HTML5 events?
Nick van den Bleeken: Except for mutation events.
John Boyer: How about DOMFocusIn and DOMFocusIn then?
Charlie Wiecha: It could be a cursor processing with no UI. There could be listeners processing it, in a server-side data-oriented event as you process each pipeline stage. The listeners make a view.
Leigh Klotz: Why would you use DOMFocusIn instead of DOMActivate?
Charlie Wiecha: For a different stage in the processing; it's attention rather than operation. I can see the need for both events.
Leigh Klotz: So we can agree with Anne von Kesteren's point that suggest that only events independent of application (mutation events, DOMActivate, DOMFocusIn/DomFocusOut) be removed from DOM Level 3 and put into an HTML5 spec.

Charlie Wiecha: Alternatively, can we live with the name change or is it a semantic change?
John Boyer: There's a time when there's no focus.

Charlie Wiecha: We should respond with both points, suggesting that it be rational to refactor the spec, but respond with the first point because we need to respond. But I'm not sure if we have decided whether when can live with the focus events.
Nick van den Bleeken: [irc] focusin vs DOMFocusIn e-mail we also discussed in July: http://lists.w3.org/Archives/Public/public-forms/2009Jul/0017.html
Charlie Wiecha: Focus still doesn't bubble, even in DOM Level 3.
Nick van den Bleeken: It's the timing.
John Boyer: focus gives you event before the focus; DOMFocusIn gives it to you after the focus. The same for focusOut.
Charlie Wiecha: So the IE events are now in DOM Level 3?
John Boyer: What does not cancellable mean? One use case is to catch the event, run a test, and cancel the event if the test fails, thus preventing focus change. Can you do this?
Charlie Wiecha: We use activate more than the focus events.
John Boyer: I've seen focusin used: when you arrive at the control, the user has already filled out other information, so you can retrieve and fill out info.
Leigh Klotz: And would that still be possible?
John Boyer: Either way. And the web service retrieval would be asynchronous anyway.
John Boyer: Whereas, with focusout, the use case is on testing and validation and the app author wants the focus to go back. What is the state of the focus if you change focus back in the event handler? With focusout it happens before it loses focus, so it's not possible.
Kenneth Sklander: The focus is taken from the element before the dispatch of this event type. From the lvl 3 spec.
Steven Pemberton: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
John Boyer: As of yesterday, on focusout is says "about to lose focus" and "before".
Nick van den Bleeken: http://www.w3.org/TR/2009/WD-DOM-Level-3-Events-20090908/Overview.html
Kenneth Sklander: I'm reading DOMFocusOut.
John Boyer: Yes, they're asking to remove DOMFocusOut.
Kenneth Sklander: In XForms only DOMFocusOut can be used to check the data.
John Boyer: Yes, in the focsuout case, there is a difference. And blur?
Kenneth Sklander: blur happens after focus.
John Boyer: Except it doesn't bubble.
Kenneth Sklander: blur doesn't bubble.
Steven Pemberton: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-uievent-event-order

  1. [user shifts focus]
  2. focusin
  3. (before first target element receives focus)
  4. focus
  5. (after first target element receives focus)
  6. DOMFocusIn
  7. (if supported)
  8. [user shifts focus]
  9. focusout
  10. (before first target element loses focus)
  11. focusin
  12. (before second target element receives focus)
  13. blur
  14. (after first target element loses focus)
  15. DOMFocusOut
  16. (if supported)
  17. focus
  18. (after second target element receives focus)
  19. DOMFocusIn
  20. (if supported)

John Boyer: focus or DOMFocusIn is OK. And blur can be used for the exit test. Does the absence of bubble on blur cause problems?
Kenneth Sklander: Yes, if you use it on a group.
John Boyer: focusin bubbles.
Kenneth Sklander: If you have setvalue on a group.
John Boyer: You'll get a focusin and that will bubble and you can run pre-processing for the group.
John Boyer: focus doesn't bubble.
Charlie Wiecha: What's the rationale?
Nick van den Bleeken: IE
John Boyer: So the feedback could be to make them bubble.
Nick van den Bleeken: So keep focusin and focusout, remove focus, blur, and DOMFocusIn and DOMFocusOut?
Steven Pemberton: Why don't we ask Doug Scheppers to join our call next week? We've got an uneasy feeling but no resolution. So he can talk to us about it.
Charlie Wiecha: We could live wit it if focus bubbled.
Steven Pemberton: But it won't.
Nick van den Bleeken: They added it because IE has it. They won't change it.
John Boyer: DOMFocusIn and DOMFocusOut are added.
Steven Pemberton: I'm sure there are A11Y issues.

John Boyer: We've identified the use cases and there seem to be problems with the elimination fo the events. I'll invite Doug Scheppers next week. s/

* XForms 1.1 PR


John Boyer: Voting closed yesterday.
Steven Pemberton: There are some comments from Mohamed Zergaoui.
John Boyer: It looks like some updates to references. He also says we should clarify the relationship to XPath 2.0 Functions and Operators.
Leigh Klotz: It's based on XPath 1.0.
Nick van den Bleeken: So can we say XPath 2.0 is for XForms 1.2?
Steven Pemberton: A future version.
John Boyer: Where do we contact him back and see if we satisfy him for these member-only comments?
Steven Pemberton: w3c-archive
John Boyer: Then what do we have to say? We have an XPath 2.0 implementor.
Nick van den Bleeken: Chiba also uses XPath 2.0.
John Boyer: We deprecated the if() function for anticipated future implementations, but we didn't explain the full relationship.
John Boyer: Why was if deprecated if it's in the xforms namespace?
Nick van den Bleeken: The XPath 2.0 parser fails even if prefixed. You can use uppercase.
John Boyer: Really?
Nick van den Bleeken: I'm quit sure but I can look it up.
John Boyer: Maybe because it might be the default namespace.

John Boyer: Where do we put the note?
Leigh Klotz: Maybe where we deprecated if().
John Boyer: Or more globally, in the introduction to XPath expressions: "future versions may incorporate XPath 2.0."
Steven Pemberton: And certain aspects for XForms 1.1 may be seen as preparation for that change. But run it by Mohamed.

* XForms 1.1 RelaxNG Schema

Leigh Klotz: John, is the Schema in place for XForms 1.1?
John Boyer: Yes, it's in TR space but the link is not yet in the document.
Leigh Klotz: I've been asked to provide review copies. Can you paste in the link?

* Testimonials

John Boyer: Kenneth, if you happen to want to produce a testimonial supporting XForms 1.1 that would be nice. See the XForms 1.0 ones for reference.

* XForms 1.1 PR (redux)

John Boyer: The votes are in and I think we will be closing in the next few weeks. Charlie; What about inputMode?
John Boyer: The latest email said it would have been preferreable if we were to list the attribute names but say you could be conformant without using them, but that's not the W3C process for conformance. We can say that the commenter would prefer a normative-but-optional feature but we don't have test suite entries or conforming implementations, on entry to CR, so it's not an appropriate PR process.
Charlie Wiecha: OK.

* IRC Minutes


* Meeting Ends