W3C Forms teleconference September 2, 2009

* Present

Steven Pemberton, CWI/W3C
John Boyer, IBM (chair)
Charlie Wiecha, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Erik Bruchez, Orbeon
Mark Birbeck [irc only], webBackplane

* Agenda


* Previous minutes

http://lists.w3.org/Archives/Public/public-forms/2009Aug/0027.html IRC supplement: http://www.w3.org/2009/08/26-forms-minutes.html

* Administration

John Boyer: I'll be away September 16th; Charlie will chair.
John Boyer: Also can we start 15 minutes late next week?

* Document Engineering Conference

John Boyer: Rahul and I have a paper in the Document Engineering conference, which I will be attending: REST Protocol and Packaging Format for Web Documents.
Charlie Wiecha: There's also an XForms and ODF paper.

* Next FtF

John Boyer: Oct. 1 Virtual day, Nov 2-3 and 5-6. I updated the wiki pages. November 5-6 are hosted by Xerox and 2-3 are at the tech plenary.
Charlie Wiecha: Do we know anything about the tech plenary talk registration? We talked about a panel discussion or breakout one extensibility on backplane.
Steven Pemberton: Extensibility is one of the big topics of the whole meeting. I'll send you the draft agenda.
John Boyer: The HCG is going to be talking about extensibility or accessibility on September 11.
John Boyer: 11th is accessibility. The 25th is "Testing in the Browser." I sent regrets; Charlie, you are invited.
Charlie Wiecha: I also volunteered to talk about the backplane XG results. http://www.w3.org/2009/08/28-hcg-minutes.html#item03
John Boyer: "Testing in the Browser" is a talk about using Ubiquity-like approaches to deliver W3C technology. It means testing in test deployments of W3C technology. We can use attribute decoration, but it runs afoul of the DTDs used to validate content, and unfortunately in a number of government agencies (Canadian, possibly UK and Australia) for A11Y reasons they have guidelines to validate against XHTML1 or HTML4 DTDs. So ARIA attributes for A11Y fail. So people turn to Dojo script where the content is created after the page loads, and so people test the DOM after the page loads. We're trying to get them to upgrade. We want to make sure that HTML5 recognizes an extension mechanism to validate according to a new schema or DTD for A11Y extensions. If HTML5 has no extension mechanism then it will not work.

* PR issue with inputmode

http://lists.w3.org/Archives/Public/public-forms/2009Aug/0024.html http://www.w3.org/TR/2009/PR-xforms11-20090818/#mode http://unicode.org/iso15924/iso15924-codes.html

John Boyer: We had a great deal of difficulty getting Martin to respond during last call. These comments are appropriate for last call, not for the PR transition. But we can go through them and see what we should do. We may not have to respond to these in the Disposition of Comments because it wasn't sent to www-forms-editor, but we may choose to do so anyway.
Steven Pemberton: The voting has already begun. We can make propose some changes during the transition call. We can discuss the changes now.

John Boyer: We cite another source and in that source they are capitalized.
Steven Pemberton: The only thing we can do is talk to implementors and ask what they do.
John Boyer: XForms 1.0 can be distinguished from XForms 1.1. We can say 1.0 uses small and 1.1 uses capitalized.
John Boyer: Also, note that the normative attribute inputmode is normative and its values are normative. He asks that we switch it back to normative. I don't want to do that.
Steven Pemberton: That would be a normative change. But do we have any implementations of this so far?
John Boyer: I'm not sure that we do. He says it's a normative feature, and that's true, but it is an optional feature that is a hint. So we say "if you're going to indicate this, then this is how you indicate it." I don't know of any. Ubiquity and Lotus Forms do not implement it. Does Orbeon or Chiba implement inputmode?
Nick van: Chiba doesn't implement it, as far as I know.
Erik Bruchez: No, we don't.

Steven Pemberton: He does point out some changes with the values.
John Boyer: It's still case sensitive; we just changed the first letters.
Steven Pemberton: I'd almost prefer it to be case-insensitive then.
John Boyer: I think you're right, that means we don't make 1.0 forms non-conformant. We cite another spec for the tokens. Does the Unicode Script Names list care about case?
John Boyer: We could change the case back to lowercase if it's non-normative.

Steven Pemberton: http://www.unicode.org/unicode/reports/tr24/#Values says "As with all property value aliases, the values in the file are not case sensitive, and the presence of hyphen or underscore is optional."
Steven Pemberton: So if we say it's case-insensitive...
Steven Pemberton: There's another spec that uses inputmode, right? XHTML Basic. http://www.unicode.org/unicode/reports/tr24/#Values http://www.unicode.org/unicode/reports/tr24/#Values
Steven Pemberton: The list has all caps, but the examples use lowercase.
John Boyer: In XForms 1.1?
Steven Pemberton: Yes.
John Boyer: The source document list is case-insensitive and it says underscores are optional.
Steven Pemberton: We should be saying case-insensitive; absolutely right.
John Boyer: That's in the non-normative section. We can cite the informative references.
Steven Pemberton: Could we remove the list and still cite the reference?
John Boyer: Martin asked us to keep the list.
Steven Pemberton: This comment isn't part of a vote; it's a very late last-call comment. We should collect these suggestions that don't affect conformance into a document and ask at the REC call.
John Boyer: This is editorial as it's affecting the non-normative section of the spec, so we could issue an erratum.
Leigh Klotz: What about the normative/non-normative point he makes?
Steven Pemberton: After we've exited CR he can't ask us to change the CR exit criteria.
John Boyer: The attribute
Steven Pemberton: The attribute is normative but there are no normative values for it.
John Boyer: The highest level we suggest is that if you are going to implement it then this is how. Right now it's informational.
John Boyer: This is the highest level we can achieve. We didn't identify inputmode as a feature at risk; if we had to change that we'd have to remove it.
Charlie Wiecha: How did we get through normative status in 1.0?
Steven Pemberton: It said "hint".
John Boyer: The test suite didn't test it.
Leigh Klotz: Are the values in the schema?
John Boyer: No, the type is xsd:string.

John Boyer: So should we respond to the same list or just to the commenter? In any case, we'll need a draft response. I think: we could propose (1) going to case-insensitive comparisons; (2) Appendix is remains non-normative at the current state of implementations of XForms 1.1 because the normative attribute is itself optional and the appendix specifies how it would be done, and furthermore this is not a change to our CR or CR exit criteria, so this request to change to normative is not a PR comment. The WG can advocate a normative value list for a future version of XForms.
Leigh Klotz: Are we going to put the list in the schema?
John Boyer: No, we don't want to be limiting in the future. My understanding is that we wanted to allow other values in the future without having to issue another version of XForms. We say "this list of tokens or a successor." "In most cases the script tokens correspond to Unicode scripts. Some correspond to block names in java.lang.Character."
Charlie Wiecha: He says that other values leads to non-interoperable implementations.
John Boyer: We assume they're following an updated spec. We could lock it down but then they're frozen for the future.
Charlie Wiecha: It looks like Comment 2C he expects an independent spec.
Leigh Klotz: Maybe we should ask that the I18N group come up with their own spec for this attribute and we can just use it. Maybe the right home for this attribute is an I18N Recommendation and we can invite others to use that Recommendation in conjunction with XForms.
John Boyer: That would be a good comment about future versions of XForms.
Charlie Wiecha: He says it's normative in XHTML Basic.
John Boyer: I could see an erratum to XForms 1.0 that says "case-insensitive" and "non-normative" but that would be a lot of work. For XForms 1.1 we should say case-insensitive.
Steven Pemberton: So what is the action?
John Boyer: We need to communicate back to Martin first. Would you write the text?
Steven Pemberton: Let's agree on the points: explain what we can do now, given that this comment is after last call.
Charlie Wiecha: And make suggestions about how they can get it normative?
Steven Pemberton: Suggest that the I18N group take on the module?
Charlie Wiecha: Yes, that's the gist of the conversation. It gives it normative status, and we can import it appropriately.
Leigh Klotz: Or invite it its use.
Steven Pemberton: I see Picoforms using inputmode: http://www.w3.org/MarkUp/2008/xhtml-basic-11-implementation.html
Steven Pemberton: There were two implementations there, an internal implementation of Netfront.
John Boyer: We could have two tests for required feature and one for optional.
Steven Pemberton: We have implementations of this feature as we have these implementations.
John Boyer: The test suite doesn't test it. But nonetheless we have the link here.

Action 2009-09-2.1: Steven Pemberton to explain the group position to Martin Dürst directly for http://lists.w3.org/Archives/Public/public-forms/2009Aug/0024.html

John Boyer: [irc] The inputmode attribute is listed normatively, but it is an optional feature that provides a hint to processors. Thus, the current script token list is informative of keywords that could be used. We are suggesting that if XForms processors do implement this feature, here are some values they could use. Upon entering candidate recommendation, XForms processors were not compelled to support any values of this attribute, and thus the request to change appendix E to normative is not a PR comment.

* Next Week

John Boyer: Let's pick up with external models next week.

* IRC Log


* Meeting Ends