W3C Forms teleconference June 16, 2010

* Present

Alain Couthures, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (minutes)
Uli Lissé, Dreamlabs
Charlie Wiecha, IBM
Erik Bruchez, Orbeon

* Agenda

* Previous Minutes

* Administration

Steven Pemberton: Next week I will be out (keynote in Oxford).

* Summer Vacation Schedule

http://lists.w3.org/Archives/Public/public-forms/2010Jun/0020.html http://www.w3.org/2002/09/wbs/34637/32219/

* Simon St. Laurent on standards process


Leigh Klotz: An interesting read, maybe not much discussion, here.

* Lyon

Teleconference times / Virtual Days? Meeting details

Steven Pemberton: We've got four days; I'm assuming we'll be 9-5. Will we need telecon?
Leigh Klotz: I probably won't be able to attend in person.
Steven Pemberton: My feeling is that if we're meeting for four days we don't need a virtual day. Anybody disagree?
John Boyer: No.
Steven Pemberton: Registration for TPAC is open until October 22. http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
Steven Pemberton: How many know for sure?
Alain Couthures: I'll try.
Nick van: I'll try.

* Action Item Review


Steven Pemberton: I'll go through my list and look for terribly old ones and unilaterally scrap some of them which have either happened or will never happen. I'll re-raise any that need to be done quickly.

* Input bound to boolean node and incremental


Steven Pemberton: It's a shame we didn't do this for select1.
Leigh Klotz: The @incremental default doesn't work; consider a repeat.
Nick van: John hinted that an input with enter would also commit the data and that's the "activation" of the form control. So we might say the same thing about a checkbox; that is a new event, so maybe we don't want this behavior.
Steven Pemberton: Adding new events?
Nick van: In text input, enter commits and sends DOMActivate. We don't say how a control is activated. We might say that on some devices that when you mouse a checkbox it's activated.
John Boyer: In my email, I said that seemed to work for me, and it recognized that there was a bit of button-ness about a checkbox and so when you click it you activate it.
Leigh Klotz: Where do we put this guidance? Implementors who are working hard aren't seeing it.
Nick van: We already say that when you activate the control, data is committed.
John Boyer: We give an example here of search: http://www.w3.org/TR/xforms11/#ui-input
Steven Pemberton: There's no possibility of an incomplete value with select1 or input. There is with select and with input for text. There's no doubt, so it can't mean anything else.
John Boyer: We already have a DI note at the end of #ui-input that says a graphical browser might activate according to clicking or enter.
Leigh Klotz: The text is there. I just didn't see it.
John Boyer: We can beef it up.
Leigh Klotz: After "See 8.1.2 The input Element for an example." add "for an example of this sequence, and for examples of activation."
John Boyer: And in section 8.1.2 add example of activation.
Steven Pemberton: I think we could generalize this; for example in Ubiquity there's a lat/lon control. That ought to be incremental, since clicking is enough and you don't have to navigate off.
John Boyer: Either incremental, or saying that you activate the control and that commits the value.
Nick van: It's stronger; incremental is a hint.
John Boyer: I don't think incremental is a hint; we can't rigorously define how often xforms-value-changed events happen.
Nick van: If you click it the DOMActivate happens right away whereas incremental may still pause. So I think it's better to bind it to the activate behavior.
John Boyer: So what does an HTML4 browser do? Do you get activate events?
Steven Pemberton: Alain?
Alain Couthures: A DOMActivate can be generated; I'm thinking of a test.

Action 2010-06-16.1: Alain Couthuries to investigate DOMActivate and HTML4 checkbox and report back.

Action 2010-06-16.2: John Boyer to add erratum to XForms 1.1 in section http://www.w3.org/TR/xforms11/#sequence-for-input http://www.w3.org/TR/xforms11/#sequence-for-input to add guidance on when controls get activated, and incorporate Steven Pemberton's recommendation of activation timing as defined by complete-value readiness as a result of user interaction.

* show=download or a new form control?

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

Leigh Klotz: The question remains about show=download in Erik Bruchez's writeup of submission replacement. Is it show=download or a new form control.
Steven Pemberton: My gut feeling is that it's not a form control.
Nick van: I think it needs to be a submission; later it can be a form control too if so, but the submit control already has it.
John Boyer: I'm confused about form controls. It's a third attribute on the load action?
Steven Pemberton: The suggestion as I understand it, is to unify submission and load show.
Erik Bruchez: There is an implementation problem to do this in HTML4. It would require control of the Content-Disposition header.
Alain Couthures: It's not possible with Javascript but there are some tricks.
Leigh Klotz: That's in HTML4+Javascript.
Alain Couthures: Right, with a plugin.
Erik Bruchez: My concern is that we don't want to specify something we can't implement in existing browsers. It would be a different question if we knew HTML5 would soon allow it.
Alain Couthures: No, not in HTML5.
Steven Pemberton: There are other features not implementable in XHTML4+JS.
Alain Couthures: ...
Erik Bruchez: We have a server component and we have a special appearance on output called "download." This appearance causes a download to happen and we can do this because of our server can force a content-disposition header. I would be the first to support easy download, but I'm worried that in general if we include client-side implementations, it may not be implementable.
Nick van: http://dev.w3.org/html5/webstorage/#the-localstorage-attribute
Steven Pemberton: So you're saying we need to use Content-Disposition and the server must know what we want and so we can't put it into XForms.
John Boyer: Not at the required level. At the recommended level, with the technical reason.
Erik Bruchez: There would be a lot of value. Unfortunately, if we start littering it with features that scare off implementors.
Leigh Klotz: You already have it implemented; if someone else does it, and they do it the same way as you, then we have a defacto standard.
Erik Bruchez: Would it be a show attribute on submission? We don't have that.
Leigh Klotz: That's the discussion here; what's the syntax?
Erik Bruchez: We had URIs result of XForms upload which come from the client which end up as a URL in the instance or base64, or we have a URL pointing to an external service. Imagine upload/download attachment, or store attachment in database and later download it. So the first thing we needed wasn't a submission, but it was a control with the download appearance on xf:output.
Leigh Klotz: Is it activated whenever there is a refresh?
Erik Bruchez: It appears as a link or button.
Leigh Klotz: xf:output is the least typing; you could do it with submission or xf:load (as John says) using the resource element on each.
Erik Bruchez: Imagine a repeat over multiple attachments; with a submission, you have to somehow communicate the URL to the submission.
Leigh Klotz: But it would work with xf:load and we do have that outstanding request for submission.
Erik Bruchez: Right.
Leigh Klotz: So we've got one case for xf:output implemented. If we did it with load, we'd need to have equivalence in submission.
John Boyer: Do we need to do this?
Leigh Klotz: So is this xf:output with an appearance, or is this a load and submission attribute? If we think it's the latter we should decide now as we're discussing load and appearance. If it's xf:output, we can postpone it.
John Boyer: xf:output appearance isn't interoperable as it would be a custom namespace.
Alain Couthures: I'm not against the xforms namespace.
Nick van: I would prefer it on submission and load. That might be more natural.
Steven Pemberton: I agree.
John Boyer: Third.
Leigh Klotz: That doesn't preclude xf:output appearance that Erik has done.
Steven Pemberton: Yes, he's done it interoperably.

Steven Pemberton: So?
John Boyer: It sounds like a target. We said replace would stay as all.
Steven Pemberton: target="_download"?
Erik Bruchez: We had considered the values of the target attribute might depend on the host language. It's nice to say in HTML4 that you can use target values in XForms. If we start adding values to that space it's funny.
John Boyer: It's not as funny as changing the spelling of things that are available. It's less of a problem to be a proper superset. The XForms processor adds value to the host language, using the host language extension mechanism.
Erik Bruchez: HTML4 specifies _top and _blank now. It might be a conflict to use _download.
Alain Couthures: Yes.
Erik Bruchez: It's a mix of frames and windows in HTML4.
John Boyer: So the replace attribute doesn't have the best name, and we can use replace=download and leave target as is?
Steven Pemberton: You are replacing the thing as that filename. replace=file seems as good as any.
Leigh Klotz: I doubt you can specify a full filename.
Erik Bruchez: Content-Disposition specifies the file name.
Leigh Klotz: Can we mine Content-Disposition as a source of names for attributes or values?
Steven Pemberton: From the user's point of view, I think file is the right concept.
Leigh Klotz: Resolved?
Erik Bruchez: I'm not 100% convinced.
Steven Pemberton: Let's leave it as the current.
Erik Bruchez: I don't want to drag on either.
Steven Pemberton: so replace=file is our current proposal, but not a resolution.

* IRC Minutes


* Meeting Ends