W3C Forms teleconference June 9, 2010

* Present

Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Uli Lissé, DreamLabs
Charlie Wiecha, IBM
Alain Couthuries, AgenceXML

* Agenda

* Previous Minutes

* Administration

Steven Pemberton: Welcome Alain.
Alain Couthuries: I have been working with XML for ten years and am now developing XSLTForms. I've rebuilt it from AJAXForms, and am now improving it, recently now with native XML storage.
Steven Pemberton: We expect a few new members to join but right now we're still building up to what we'll be doing in the coming time.

* Telecons

Steven Pemberton: Next week is ok but in two weeks Leigh will chair.

* HTML/XHTML Compatibility Authoring Guidelines to FPWG

http://lists.w3.org/Archives/Public/public-forms/2010Jun/0002.html

Leigh Klotz: We should read this with an eye toward what it means for XHTML+XML serving. XForms implementations should review this because of the way that MIME types work in different implementations.
Leigh Klotz: Also, it uses "normative" and "MUST" in the RFC sense, but it says it's guidelines.
Steven Pemberton: I think most use text/html for delivering documents. If you pull together we can review it for formal comment.

Action 2010-06-9.1: Leigh Klotz to review HTML/XHTML Compatibility Authoring Guidelines to FPWG http://lists.w3.org/Archives/Public/public-forms/2010Jun/0002.html

* Life After Rechartering: Making Progress

http://lists.w3.org/Archives/Public/public-forms/2010Jun/att-0001/2010-06-02.html#topic7

Steven Pemberton: So we decided to work in the wiki for now and not have a monolithic spec, and thus not have a single editor. I did say I'd have a look at splitting it up into modules, but for the time being we've got the wiki.

* Mediawiki to SpecXML Converter

http://lists.w3.org/Archives/Public/public-forms/2010Jun/0003.html

Leigh Klotz: This validates the approach; it lives outside MediaWiki and it converts Wiki text markup to XML of various sorts. It doesn't convert to SpecML but we could do that or we could write a converter for it. So it validates the approach.
Charlie Wiecha: A template would be nice too. A mockup of a module with examples for markup fragments, tables, references, etc.
Steven Pemberton: Should we take existing spec and wikify it?
Charlie Wiecha: That would be a good reality check.
Steven Pemberton: Are you willing to do that with a section?
Charlie Wiecha: OK.
Leigh Klotz: I will check it to make sure it's convertible.

Action 2010-06-9.2: Charlie Wiecha to produce sample template for Wikified SpecML input with real examples from existing XForms Recommendation.

* proposal for new submission replace mode "new"

Original thread http://lists.w3.org/Archives/Public/www-forms/2010May/0018.html http://lists.w3.org/Archives/Public/www-forms/2010Jun/0000.html Continue last week's discussion http://lists.w3.org/Archives/Public/public-forms/2010Jun/att-0001/2010-06-02.html#topic8

Steven Pemberton: Who will summarize?
Erik Bruchez: We talked submission replace=all. There's no way as I know to ensure that a replacement terminates the current XForms processor. In cases where that could happen are a replace=all which returns but the current document isn't replaced. Another is where the browser opens the document in a different window, in which case the same thing can happen. So it seems that replace=all doesn't always require replacing the current page; there are cases where it doesn't happen. That was the argument against adding a new replace value such as replace="new". We're stuck with the name replace. That's one reason I wasn't in favor of adding a new value of the attribute replace, since it already does behave like the proposed new.
Steven Pemberton: Our spec requires things on replace=all that aren't possible.
Nick van: The spec is updated already and doesn't; it says MAY.
Erik Bruchez: In view of current implementations with replace=all, the spec require you to replace (shutdown?) the current processor but clearly there are places where that's not going to happen. So the spec needs to be changed. We have revised, as Nick points out, cases where the processor is shut down and that implementations may not have to dispatch xforms-submit-done or xforms-submit-error events.
Steven Pemberton: From your summary, I gather that you think we don't have to change anything.
Erik Bruchez: I think part of the discussion started when Joern asked for a new target attribute on submission, target="_blank" or window ID. Someone said that it would change the behavior of replace=all because it doesn't replace the current document, and so we needed replace="new" but since we already have cases where replace=all doesn't replace the current document, we don't need replace="new".
Steven Pemberton: So you're saying we don't have to worry; the word "replace" isn't right.
Steven Pemberton: So, can we leave it as it is?
Leigh Klotz: What about the new thing?
Steven Pemberton: That's the target attribute.
Leigh Klotz: Is that done?
Nick van: It's in the wiki: http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding we use @replace=all
Steven Pemberton: Then we're good to go, hearing no objections...
Erik Bruchez: Should we clarify the spec to say that replace=all doesn't replace all always. http://www.w3.org/TR/xforms11/#submit-evt-submit
Erik Bruchez:

when the value of the replace attribute on element submission is "all", the event xforms-submit-done may be dispatched with appropriate context information, and submit processing concludes with entire containing document being replaced with the returned body

Steven Pemberton: Yes, we need to make changes because target may be specified.
Leigh Klotz: That needs to go in the wiki page Nick posted.
Erik Bruchez: Or implementations can be given freedom. Should I edit the wiki.
Leigh Klotz: I think we should capture the decisions there. And I'd suggest a note about HTTP header Content-Disposition because we need to give guidance to XForms agents.
Alain Couthuries: How about using replace="none"
Charlie Wiecha: Sometimes the referent of replace is the target and sometimes the referent is the content.
Steven Pemberton: Maybe. I'm not so worried about that. The idea of replace="new" was to say that something somewhere else is being replaced.
Leigh Klotz: What do we want the user agent to do with Content-Disposition: attachment?
Nick van: And target="_self"
Erik Bruchez: It depends on external factors such as content size and Content Disposition, our attributes, and possibly other factors. I think it's confusing to say that if I did replace="new" target="_self" to mean replace="all" but replace="all" and the Content-Type is application/pdf and the browser opens a new page, then that's the same as replace="new" target="_blank", but it's not because it opens in the PDF Viewer, not the browser window. So replace="all" doesn't guarantee replacement of the current containing document and replace="new" wouldn't either. I don't think we can enforce any of this.
Steven Pemberton: I hear what you're saying; leave it as it is?
Erik Bruchez: I think we should clarify that what replace="all" does, that it might not replace the current document.
Leigh Klotz: Then, do we want to make an incompatible change?
Steven Pemberton: No I'd like not to make too much of a change until 2.0.

Resolution 2010-06-9.1: For http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding we use @replace="all" with @target on submission rather than making up a new @replace value.

Action 2010-06-9.3: Erik Bruchez to update http://www.w3.org/MarkUp/Forms/wiki/Submission_Embedding with notes about when replace="all" doesn't.

* @iterate

http://lists.w3.org/Archives/Public/public-forms/2010May/0005.html http://lists.w3.org/Archives/Public/public-forms/2010May/att-0025/2010-05-26.html#topic6

Steven Pemberton: So what's the result when you delete a node? I think you have to define that it's the first of those, you make a copy.
Nick van: John had trouble with that, in XPath 1.0 because those nodes aren't rooted in a document any more, or in a different document. But we already have functions that return nodes from different documents so I'm not sure that's a problem.
Leigh Klotz: The instance function.
Erik Bruchez: What is the problem? I don't think we've resolved what happens with iterate when you delete the current node or a subsequent node.
Leigh Klotz: John said that if an action deletes its context node, the actions continue but any ones that refer to the context node have no effect. This leaves only setfocus. I ran into this with the following use case: delete a node locally if it has a uniqid or delete it via submission if it does. Now you have an action which is sure to delete its own context node and then try to refer to the node later, via @if:

<action ev:event="DOMActivate"<<delete if="uniqid = ''' .../<<send if="uniqid != ''"/<</action<

Erik Bruchez: So we need to say what to do with deleted nodes and actions.
Nick van: If you use the event function there are nodes returned from the DOM tree.
Erik Bruchez: There's only one case; headers I believe. So you could use a setvalue function to modify the nodes returned by the event function.
Nick van: So a node removed from an instance isn't much different; the event data isn't in an instance either.
Erik Bruchez: Someone could argue that there's a difference: the event function returns a node in an XPath 1.0 data model, but in the case we're describing you have orphan elements in no document. In XPath 2, there's no problem with that type of thing.
Nick van: Such an implementation could place deleted nodes into documents, then.
Erik Bruchez: They could.
Nick van: In http://www.w3.org/TR/xforms11/#submit-evt-submit-serialize event submit-serialize submission-body is a node-set which isn't in an instance.
Erik Bruchez: It doesn't say it's not in a document, but it's not in an existing instance. So we cannot simply say actions such as setvalue, delete, and insert, or we imply at least that setvalue should work on non-instance documents. There's a step then to deleted nodes would respond to actions.
Nick van:
<action context="event(submission-body)">...</action>

Erik Bruchez: So, naively, you have a pointer to a node and pass it to xpath and hope for the best with detached nodes. In our implementation that works fine. If it happens that the node isn't in a document, that's fine.
Leigh Klotz: For XPath 2, it's defined to work.
Nick van: It's true in at least one XPath 1.0 implementation. It's not a problem in implementations we've used.

Steven Pemberton: What is our conclusion? That it's not a problem?
Alain Couthuries: It might be a problem for XSLTForms.
Leigh Klotz: Operating on deleted nodes in XSLTForms produces errors, at least in the version which doesn't use native XML.
Alain Couthuries: It might change.
Leigh Klotz: I think we need to poll John for consensus since everyone else seems.

* XHTML Modularization

Steven Pemberton: Please vote for this: http://www.w3.org/2002/09/wbs/33280/xhtmlmod2010/
Steven Pemberton: We may use this for XForms 1.2 Modularization.

* IRC Minutes

http://www.w3.org/2010/06/09-forms-minutes.html

* Meeting Ends