W3C Forms teleconference April 22, 2009

* Present

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

* Agenda


* Previous Minutes

* Next F2F

Charlie Wiecha: I've reserved rooms at the IBM South Bank location.
Steven Pemberton: It's a wonderful location in London.
John Boyer: Location details?

Action 2009-04-22.1: Charlie Wiecha to put location details for next F2F on the wiki.

Steven Pemberton: Mark is organizing a meeting.
Charlie Wiecha: Yes, and the presentations.

John Boyer: And a sign-up page.
Charlie Wiecha: Maybe Mark or Paul who are co-hosting could list the accomodations.
Steven Pemberton: Here's my London guide: http://www.internetguideto.com/london/

John Boyer: We need the agenda items.
Steven Pemberton: The is the last-but-one in this current charter. I'd like to talk about XForms 2.0 so we could start planning a charter.

* Backplane

John Boyer: We're pushing ahead with our finance application, and integration with SVG components, and structural transformations. One of the XForms 2.0 topics is structural binds in addition to value binds; we need a list over another.
John Boyer: We also discussed df-dojo-type=repeat. Have you followed Sam Ruby's blog post about HTML re-unification? http://intertwingly.net/blog/2009/04/08/HTML-Reunification It mentions Ubiquity as a project using an HTML parser to provide extensibility. It comes down to DOM consistency (colons, local names). I did respond after a few days; there wasn't any discussion after it. We have a lot of concepts in the Backplane that apply here, even in a non-XML way. There has been some disagreement and discussion.
John Boyer: We're still looking at integrating Jacks' Ubiquity-SMIL that Mark did. There's some sequential parallel execution work there and Jack has picked it back up.
John Boyer: I'll posted a revised draft of the XG report. We did get a charter extension through October and then wrap up the report.

* X4H

Leigh Klotz: Which of these should I add the attributes to?
John Boyer: It ould be more HTML5 and XHTML5.
Leigh Klotz: Which does Ubiquity XForms work with?
John Boyer: Mostly HTML4. There are some XHTML issues.
Charlie Wiecha: There are a couple of settings. The XHTML one is mostly OK. You sometimes have to tweak browser setings.
John Boyer: So they should work in current and future.
Charlie Wiecha: It does point out the topic of modularity, that we have to have this diiscussion.
Leigh Klotz: Parser is the syntax; Preset is the Schema.
John Boyer: So hopefully it would appear as a new option on each. That helps makes the modularity point.
Leigh Klotz: As Charlie pointed out.

* Filename and mediatype under submission as multipart/form-data


John Boyer: Erik asks if "known" at serialization means it must be known from the instance.
Steven Pemberton: So "if the filename is available" is about the file coming from a scanner?
John Boyer: Yes, it's about device independence.
Leigh Klotz: We put in these binding sites because I said there was no way to serialize the info in XML instead of MIME headers. I think Dave Hyatt suggested the bindings and Micah Dubinko did it. There was no thought given to reading it back in from the instance.
Erik Bruchez: Yes, this is the same as the question before. Are they available through magic means as the file is, and it's up to the XForms implementation what available means? The filename may be available, but the mediatype may not. After that step is over, does available mean stored in the instance or obtained?
Leigh Klotz: Historically this was designed to work by magic, and when we added the bindings we considered only writes to the instance. So if someone changes the instance afterward, we gave no thought to what happens to serialization after.
Erik Bruchez: You can expect a serialization to pick them up.
John Boyer: Upload makes the setting and you can change it after.
Leigh Klotz: Yes, but when you serialize, say as multipart/form-data, do we follow the binding and serialize it based on the changed data?
Erik Bruchez: You can imagine an input field that lets the user to provide a mediatype. However, if the form author doesn't do that, what happens during serialization? Is it unknown, or obtained magically?
Leigh Klotz: I think personally both use cases ought to work, but I don't think we've given much thought to it and I don't know that the spec says it.
Erik Bruchez: I think there's two things: do we want to do it that way, and if so, clarify the spec?
Leigh Klotz: What do you currently do?
Erik Bruchez: We look at bindings; and we decide they are not available if there are no bindings. We do not implement the magic aspects. We do implement the modified versions. But I would have to double check that.
Leigh Klotz: What do you do about xs:anyURI binding?
Erik Bruchez: We do not implement what the group decided; we check all the URIs and dereference them all. Actually, I will have to check the code. As we saw last week we have some issues.
Leigh Klotz: I think last time we discussed an internal MIP (covered under security reasons) that marks a node as an uploaded content, so that you prevent script from uploading password files. You might as well store the filename and mediatype internally there, so you can serialize it as MIME headers even if there is no filename or mediatype binding into the instance.
Erik Bruchez: Yes, it's not hard to implement, but do we do this and then do we clarify the spec? We need to clarify what "available" means.
Leigh Klotz: It always worked before we added the binding, and that's what "avaialble" referered to.
John Boyer: I got the action to clarify the spec. We need to say what it does with the node values and the values that were gathered by the form control.
John Boyer: "Clarify that upload activation produces content and possibly filename and mediatype info as metadata. If available, filename and mediatype are copied to instance data if upload filename and mediatype elements are specified. At serialization, filename and mediatype from instance data are used if upload filename and mediatype are specified; otherwise, filename and mediatype are drawn from upload metadata, if they were available at time of upload activation."
Leigh Klotz: It works for me.
John Boyer: Does that work for you Erik?
Erik Bruchez: Looks good.

Action 2009-04-22.2: John Boyer to clarify upload filename and mediatype handling as described in minutes.

* repeat and relevance/enabled/disabled


John Boyer: This is from Vlad, who works with me. I dealt with the 8.1.1 editorial issue.
John Boyer: The question is why a repeat does not receive relevance events. The reason is that it does not have a single-node binding. However, as a container, it could be based on all of the things which it contains. As a triage, it doesn't sound like 1.1; it could be 1.2 or beyond. Is that fair?
Charlie Wiecha: Yes. I have sympathy and I have some related issues. Also filtering value-changed events at the repeat level. I think it's not 2.0, but I think the event functionality at the container level is limited.
Leigh Klotz: I've also had some issues in a project we did with disabled items in itemsets.
Charlie Wiecha: We need to think through the hierarchy of those events.
John Boyer: And XML Signatures and repeat: the repeat itself at a visual level you can think of it styled with a border, so it has a visual countenance, so it starts to matter when you're deciding what's signed.
Charlie Wiecha: The pie chart is a visualization of repeat items. It's hard in Ubiquity to figure out when to change the visualization because we don't have repeat-level event support.
John Boyer: We thought about the context attribute everywhere with a defined run order. So if we put a context or a nodeset on a repeat, it's not a big stretch to put a single-node binding ref to provide a context for the subsequent nodeset, but also relevance.
Charlie Wiecha: There's a useful combination that's useful elsewhere.
John Boyer: You could wrap a group around the repeat; it's like select/itemset. Maybe that's good enough. But in terms of issue classification, it's an issue, but not 1.1. So move to 1.2+ discussion.

Resolution 2009-04-22.1: http://lists.w3.org/Archives/Public/www-forms/2009Mar/0007.html is an issue but beyond 1.1.

* Clashes of XHTML2 and XForms

http://lists.w3.org/Archives/Public/public-forms/2009Mar/0020.html esp. target on submission http://lists.w3.org/Archives/Public/public-forms/2009Mar/0048.html

Steven Pemberton: We have a virtual F2F tomorrow and will be talking about this as well.
John Boyer: The big issue is the target attribute on submission.
Steven Pemberton: And http://lists.w3.org/Archives/Public/public-forms/2008Sep/0029.html
Steven Pemberton: Markus Gylling noticed this when he started producing the RNG Schema for XHTML2.

John Boyer: It looks like resource, encoding, and target.
Steven Pemberton: For encoding I don't think there's a clash.
John Boyer: And resource.
Steven Pemberton: I believe it was Mark's opinion that resource wasn't a problem.
John Boyer: That boils down to target. We have it to submission and dispatch.

John Boyer: Have you had further discussion on alternatives?
Steven Pemberton: It would be a bad idea to have the same attribute mean different things in different places, since the general one appears everywhere. It makes life difficult for the author to have target mean something different in one place and have a different syntax. If the syntax is the same it doesn't matter that the meaning is slightly different.

John Boyer: The last one doesn't solve it because there's no namespace so you don't know what comes from XForms and what doesn't. So use xf:target?
Nick van: What does target in XHTML2 do other than an a element?
Steven Pemberton: href is also common now. You can put it on any element.
Nick van: Does href need to appear on submission? Does it make sense?
Steven Pemberton: XForms is full of things that have unexpected uses so I'm reluctant to say no.
Nick van: How about in the head? You can't click on it.
Steven Pemberton: But you could send DOMActivate. If the syntax is compatible, but they'er not. The normal target is just an identifier; XForms has an XPath syntax.
Leigh Klotz: Do we have a target element?
John Boyer: No, because it's already XPath.
Leigh Klotz: So just turn target into an child element of submission and use @ref and @value.
John Boyer: But what about dispatch/@target?
Leigh Klotz: But that's different; so we have to problems. @target means two things and @target clashes with XHTML2 @target.
John Boyer: Or just rename target.
John Boyer: How about having XHTML2 rename submission/@target on import.
Nick van: It's already out in XForms 1.1.
John Boyer: When the attribute is on xf:submission it's called target, but when you have xhtml2's submission, the attribute name could be @dest.
Steven Pemberton: We could make it an operation of introducing a new attribute and deprecating the old one, so in XForms outside XHTML2 it continues to work, but we have an alternative which is the only one that works in XHTML2. In XML Events 2 it's already called targetid for dispatch. That that one is less of a problem, I think. So we could have target and targetid on dispatch to allow for a transition period.
Charlie Wiecha: That lets the same content be used in both contexts.
Steven Pemberton: We don't rename it; we add an extra equivalent attribute and deprecate the old one.
Leigh Klotz: And say what to do when both are there.
John Boyer: Use the new one.

Steven Pemberton: back in a minute.

John Boyer: So on XForms submission, what do we call that new attribute.
Leigh Klotz: Just make it a child element and don't add an attribute.
Nick van: We've never done that.
John Boyer: mediatype child element and @mediatype on upload are different.
Nick van: I personally prefer to have attributes.
Steven Pemberton: @targetref
John Boyer: By calling it targetref we can still have our target at some later point in time.
John Boyer: What do you think is best?
Steven Pemberton: targetref
Charlie Wiecha: yup
Nick van: I prefer an attribute
John Boyer: +1 targetref
Nick van: +1 targetref (no strong opinion about the name)
John Boyer: This is an XForms 1.1 change, right Steven?
Steven Pemberton: Yes.
John Boyer: So we add @targetid and @targetref and in XHTML2 you ignore the deprecated attributes @target on dispatch and submission.
Steven Pemberton: Yes.
John Boyer: But you're comfortable with leaving @resource?
Steven Pemberton: Yes, because the syntax is the same?
John Boyer: So are we resolved to add @targetid to dispatch and @targetref to submission?

Resolution 2009-04-22.2: We add @targetid to dispatch and @targetref to submission in XForms 1.1 and deprecate @target.

Action 2009-04-22.3: John Boyer to add @targetid to dispatch and @targetref to submission in XForms 1.1 and deprecate @target.

John Boyer: And test cases? And the schema?

Leigh Klotz: Should we remove the test for deprecated features?
Nick van: Or make them not required?
Charlie Wiecha: We do test @resource and @action.
Nick van: Is it mandatory?
John Boyer: Yes.
Leigh Klotz: But @target can't be mandatory since XHTML2 isn't going to do it?
John Boyer: Let's just add the test.
Leigh Klotz: But how can it be required?
John Boyer: It's the XForms 1.1 namespace. We can change the status of tests for deprecated attributes to be recommended.

Action 2009-04-22.4: Nick van den Bleeken to add required tests for @target to @targetid to dispatch and @targetref to submission in XForms 1.1 tests and change the @target tests on dispatch and submission to be recommended.

* IRC Minutes


* Meeting Ends