W3C Forms teleconference June 2, 2010

* Present

Charlie Wiecha, IBM
Steven Pemberton, CWI/W3C
Erik Bruchez, Orbeon
Leigh Klotz, Xerox
Uli Lissé, DreamLab
John Boyer, IBM
Nick van den Bleeken, Inventive Designers

* Agenda


* Previous Minutes

* Administration

Steven Pemberton: Alain Couthuries won't be joining us today.
Steven Pemberton: I tried XSLTForms with XForms as the default namespace and it just worked.
Leigh Klotz: I think IE fails if you start with XHTML as default, switch on a group to XForms as default, and then use an XHTML prefix inside that.

* Announcement

Charlie Wiecha: John was named one IBM Distinguished Engineer, in recognition for his work on standards and product architecture.
John Boyer: Thank you.

* Summertime Questionaire

Steven Pemberton: I'll organize it.

* Action Items


* Life After Rechartering; Making Progress

Wiki? Modules? Core? Editors?

** Modules

Leigh Klotz: Can we publish modules, small work items?
Steven Pemberton: RDFa worked well with modularization. In the long run, it's a worthwhile opportunity. The initial hump to split it up is hard. Do we want to try to get over it?
Nick van: Well, we've had one big module XForms 1.1 and we write on top of that.
John Boyer: I believe the charter says "XForms 1.2 Specifications" (btw please update the public page to point to the new charter).
Leigh Klotz: Maybe Steven can lead us towards the hump, but we can also start with small modular specs for things we already have in the wiki.

** Wiki

Steven Pemberton: The toolset I use at the moment and the current spec don't fit. We're committed to XMLSpec.
Charlie Wiecha: It becomes more feasible in smaller units. XMLSpec isn't that hard.
John Boyer: I agree; the full spec is organized by chapters which roughly map to modules. It's harder to fully separate those into separate modules; that continues to be a large engineering task, but to the extent practical they are separate. New thin specs with new functionality on switch, or submission, for example, might eventually be merged in but at least it's workable. And it gets us early traction.
Erik Bruchez: I agree and it's not different from what we're doing. It would be a huge mistake to spend significant time purely on modularizing.
Nick van: That's also my opinion.
John Boyer: Small and independently edited; I have to write some actions for the switch element. I also have to do XForms 1.1 SE, but there are champions for various features, and for a small spec it's not a huge hump to get to the XMLSpec world.
Charlie Wiecha: Oasys has no consistent spec document architecture.
Leigh Klotz: I wonder if Mediawiki can support an XMLSpec plugin.
Steven Pemberton: I've been wondering about that as well.
Leigh Klotz: You'd still have to snapshot it.
John Boyer: I wonder if there are any new pubrules for the new web look.
Steven Pemberton: I believe that's on hold for the moment; the new spec style isn't required, I believe.
Leigh Klotz: I'll take a look at Mediawiki. Maybe we can use it as an editing tool for and snapshot it eventually.
John Boyer: Even if you don't have the process and manually convert to XML Spec, the hard part is getting the content.
Charlie Wiecha: Call me crusty, but I find XML more user friendly than Wiki markup.
Steven Pemberton: Yes, but a live central copy that you can edit at any moment also has some attraction.
Charlie Wiecha: The centrality is more important than the WYSIWYG. I always have to use the language. But having a central copy is a win.
Steven Pemberton: Is there a WYSIWYG editor for XMLSpec?
Charlie Wiecha: I just look at snapshots. I'm fairly happy with the markup. It took half a day.
Nick van: In Eclipse, it generates the HTML.
Erik Bruchez: Mediawiki may have a WYSIWYG editor at some point, so the Wiki syntax issue may go away.
Leigh Klotz: If we're going to generate semantic markup the WYSIWYG editor won't help.
Erik Bruchez: So you can do that in Mediawiki?
Leigh Klotz: You can use wiki syntax macros to generate a microformat with class attributes and then use XSLT.
Erik Bruchez: I share Charlie's concern but I believe the central copy is good.
Steven Pemberton: OK so we can all live with it.

** Modules



Steven Pemberton: http://www.w3.org/MarkUp/Forms/wiki/@context_everywhere
John Boyer: That's easier as a module than a full-spec, because it would make comments that adjust everywhere.

case() function


John Boyer: Could be lumped in with switch updates, or stand alone.
Steven Pemberton: It's small enough to go in with the other functions.
Leigh Klotz: Or switch changes.
Steven Pemberton: That's much more of a delta spec rather than a module as it changes what we already have; context-everywhere is just a module with a separate spec.
John Boyer: It would change how XPath is interpreted everywhere and has an effect on actions, UI control, and bind.
Steven Pemberton: So you don't think it's separable?
John Boyer: It changes behavior but it may be OK.
Leigh Klotz: I think we can loosen up a little.
Steven Pemberton: So is it a separate spec?
Leigh Klotz: We don't know, possibly with switch updates.

Model-based switching

John Boyer: http://www.w3.org/MarkUp/Forms/wiki/Model-based_switching_with_switch
John Boyer: They're tangentially related, but both related to switch. They'll end up in separate places in a full spec.
Leigh Klotz: We may not publish a big spec with all that in it; we might publish a smaller "Core" spec.
John Boyer: For now we should proceed with small delta specs.

** Process

Steven Pemberton: For the short term, we should look at delta specs, then modules to merge them into, with an aim not to have to produce a monolithic spec again. That means a one-time modularization.
Leigh Klotz: And we don't front-load the modularization.
Steven Pemberton: I still feel a bit dubious about distributing work before the WG takes its final form. We are expecting new members. It's good if people will commit to doing work now. I'll start looking into the modularization now. If others are interested in some of the issues in 1.2.
Leigh Klotz: I think we can continue to edit things in the wiki as we've been.
Steven Pemberton: True.
John Boyer: I'm committed to the "model-based switching with switch." And the MIPS topic.
Steven Pemberton: I thought we'd agreed to add pattern to the MIPs.
John Boyer: I remember it being discussed.
Nick van: There is a pattern function in XPath 2.0 already.
Steven Pemberton: Perhaps that's why I remembered we discussed it.
John Boyer: What's it called?
Nick van: It's a search function.
John Boyer: One of the advantages to XPath 2.0 is that it provides regular expressions.
Steven Pemberton: Also you can write your own schema. Pattern is the only part that isn't built in.
Leigh Klotz: Plus minInclusive, maxExclusive, etc.
Nick van: The matches function.

** Editors

Steven Pemberton: So work in the Wiki now on parts that you champion and we'll move on for now.

* proposal for new submission replace mode new

original thread http://lists.w3.org/Archives/Public/www-forms/2010May/0018.html New discussion this week: http://lists.w3.org/Archives/Public/www-forms/2010Jun/0000.html

John Boyer: So we might have a different value for @replace to explicitly set up the behavior for @target, instead of using replace=all.
Nick van: As Erik pointed out, sometimes replace=all isn't an HTML filed, and in HTML4 sometimes the page isn't replaced either.
John Boyer: That's an interesting, but separate, question. Our language says that the document is replaced by the new content. If that's wrong with target we need to fix it.
Nick van: It may be that replace=all needs freedom to decide to shut down the form or not.
John Boyer: Then it's replace=host instead of replace=all.
Erik Bruchez: We had questions about xforms-submit-done and xforms-submit-error; we decided it "may" not be dispatched due to HTML4 integration issues. Browsers may replace documents, or do a submission and get a stream, but in the general case, you if you give control, the XForms processor may or may not be alive. It's not the case in general, and we should let the implementors load the new document in same window, new window, download, etc.
John Boyer: In replace=all we already expect that XForms implementations will delegate that to user agents.
Erik Bruchez: Then replace is the problem, not "all".
John Boyer: The name replace is the cause of our problems.
Steven Pemberton: Because people misinterpret the word "replace"?
John Boyer: What do you replace with replace=all target=_blank ?
Steven Pemberton: I see what you mean.
John Boyer: http://www.w3.org/TR/xforms11/#submit-evt-submit "Entire containing document being replaced". Erik says that's what happens sometimes. If the browser doesn't have a plugin that might be the case.
Leigh Klotz: You use "Content-disposition: attachment;"
Erik Bruchez: There was a discussion about replacement in XSLTForms. It can use XHR to get the document and replace the current content of the window with it.
John Boyer: I think we deliberately didn't allow that because it changes the baseurl.
Erik Bruchez: HTML5 has a history manager and there may or may not be a way to change that. Even if it's true today, it might not be true tomorrow. I pointed out that it may be possible to ensure it's an actual replacement, but with a hybrid implementation like ours, you rely on the server sending content, and if it's sent as a result of an HTML4 form submission, you have no control over what the browser will do. So I would like to leave open the possibility that even with replace=all you might lose control over what gets replaced.
Charlie Wiecha: [leaves]
John Boyer: Erik says that's already the case; we don't do step 1 already. Replace all means replace all of something, but it might be all of a file, or all of a window, or even all of a div.
Erik Bruchez: I guess retrospectively it wasn't a good name.
Leigh Klotz: We got it from XLink, show=replace.
Steven Pemberton: We'll have to do this next week.

* IRC Minutes


* Meeting Ends