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
John Boyer: I'll be away September
16th; Charlie will chair.
John Boyer: Also can we start 15
minutes late next week?
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.
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.
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.
John Boyer: Let's pick up with external models next week.