W3C Forms teleconference October 31, 2007

* Present

Blake Jones, ViewPlus/DAISY
Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Steven Pemberton, CWI/W3C
Keith Wells, IBM
Erik Bruchez, Orbeon [late]

* Agenda


* Previous Minutes

http://lists.w3.org/Archives/Public/public-forms/2007Oct/0113.html IRC supplement: http://www.w3.org/2007/10/24-forms-minutes.html

* Next FtF


John Boyer: We should discuss the features at risk. In the status of the document they now require what features we feel might cause a problem for implementers; if they don't get implemented, they could be removed and still proceed directly to PR.
Steven Pemberton: So if we say they're at risk then we don't have to go through last call.
John Boyer: There's also a slightly-different set of last call requirements: two inter-operating implementations of every feature, and not one complete definition of everything.
Steven Pemberton: We did that because it was a good idea.
Leigh Klotz: That was a last call comment.
John Boyer: It depends on how many we have signing up for reference implementations; if only two companies sign up, then we have to have two full implementations.
Steven Pemberton: I see.
John Boyer: Do we have anybody signed up yet?
Steven Pemberton: Who are the candidates? Mark Birbeck, Nick, Mark Seaborne?
John Boyer: PicoForms had said they wouldn't have 1.1 full but even partial implementations would be useful.
Mark Birbeck: [joins]
John Boyer: Mark, would FormsPlayer be ready?
Mark Birbeck: What is the timescale?
John Boyer: Until the end of May at least. The process document says I should have a list for transition.
Mark Birbeck: By May?
John Boyer: For transition to CR, mid-November.
Steven Pemberton: And we really do need three, to be on the safe side.
John Boyer: The more the merrier. Then we can figure out where the work is to do.
Mark Birbeck: I got the impression that on the FireFox forum they weren't planning all the features.
John Boyer: I don't think they'll have a full 1.1 in that timeframe. And I don't know whether SATEC stands. Two implementations of each feature is enough to get beyond CR.
Leigh Klotz: And the list of features?
John Boyer: In the status of the document section, we have to say what we think are the exit criteria. What I said for now is that we'd have a test suite and an implementation report for at least two for each test of a required feature. That's different than saying two interoperable implementations for each test; we can make things be should or may.
Nick van: [irc] need to talk to Joern about this, I'm doing quite some work on chiba in my spare time, but won't be able to implement all the features in my spare time. I'm currently switching the XPath engine and that is quit some work...
Charlie Wiecha: That sounds like a lot of work.
John Boyer: It may be better than removing features. So we are defining features in terms of the test suite. There could be many more tests than what we have.
Leigh Klotz: So you are expecting the number of tests to increase before we get out of CR?
John Boyer: It may. We may add or modify the tests; we're not required to nail them down to transition to CR.

* Issues with datatype validation


John Boyer: We don't say how the schemas are applied to the data. The implication is that we apply all schemas to all data. Then we have type libraries; they declare types, but not elements or attributes. So, one of the classic type libraries is the XForms type library that consists of our date and integer types. You'll get an error that says there is no type declaration for this element.
Leigh Klotz: That's the question about lax processing vs. strict processing.
John Boyer: It says processors may continue to validate the content of the element. Processors aren't required to do the lax validation of the content, and we kind of rely on that for xsi:type, but the root level element is reported as not valid according to a strict processor.
Leigh Klotz: What is a strict processor?
John Boyer: The default is strict processor.
Leigh Klotz: Yes, but it's clear that it works so we just have imprecision in our spec.
John Boyer: The easiest thing to say is that we have a general schema problem and we could live with the Schema default being strict, and defer this issue to a future release. The next step is to define a type library class of Schema, or Erik's idea of taking a page from XSLT and apply a validation attribute to the instance.
Leigh Klotz: I proposed the three rules for when there are declarations and not in the message and I think they work; with the exception of the xmlns="".
John Boyer: The interfaces aren't there.
Leigh Klotz: I think I got this from Uche Ogbuji at Microsoft on xml-dev [ http://lists.xml.org/archives/xml-dev/200209/msg00089.html], but the idea when I moved the schemas from the instance to the attribute so they would be shared was that the processor would build up a schema in the no-namespace with includes for the mentioned schemas. So the three rules would then be applied.
Erik Bruchez: [arrives]
John Boyer: Erik, would a note to that effect work?
Erik Bruchez: What are the rules for when to do lax?
Leigh Klotz: If there is no element or attribute definitions.
Erik Bruchez: So we have to do lax processing and then you iterate and find other elements inside and validate them?
John Boyer: I'd like to avoid having to alter the schema engine.
Erik Bruchez: The schema spec doesn't say this is the only way to process it; it's up to the application to do it. It looks like your schema validator does it in a certain way.
John Boyer: Leigh said that you could do it with a schema that includes others.
Leigh Klotz: That's how we planned to do it but when I checked with implementers (Kenneth and David at the SAP F2F) they said they wrote their own.
John Boyer: I think we can make this an implementation note.
Leigh Klotz: I think we need to be clear about what we want, and leave it up to implementers how to say it.
John Boyer: Can you and Erik work on it today?
Leigh Klotz: I share Erik's concern but want to decide whether we leave it as it is, or put in the goals.
John Boyer: Can you get this done today?
Leigh Klotz: Yes.
Erik Bruchez: I'll do my best.

Action 2007-10-31.1: Leigh Klotz and Erik Bruchez and write up specxml for inclusion in XForms 1.1 to answer issue http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=87

John Boyer: This is our last open issue. We have a few approved items that need work.

* Completion of action for issue 106, input mode


John Boyer: Steven have you heard any more on this?
Steven Pemberton: I haven't heard anything back.
John Boyer: Is it informative?
Steven Pemberton: It's certainly optional; I don't know if it's informative.
John Boyer: Could you ask for it by Friday?
Steven Pemberton: Done.

* Completion of issue 72 (inline controls)


John Boyer: I can do this.
Steven Pemberton: Thank you. I'm in a crunch.
John Boyer: The group agreed to language like output, with display:inline being default styling and they wanted that on all for controls. Do we want that on repeat/switch/group or should they be block? I'm ok with either one.
Steven Pemberton: Yes, sounds like block to me, really.
Mark Birbeck: In XHTML we have block level, etc.
Steven Pemberton: That's CSS. CSS took those terms over from HTML, but then there was a misunderstanding and CSS happened to use the same word. In XHTML we use new terms. These are CSS terms we're talking about now.
Mark Birbeck: Aren't these what we would have called block-level elements? You could have a group in a span, or a repeat, for example. You could flip a coin and make a case for inline or block.
John Boyer: Especially if it's the default.
Steven Pemberton: We have to say one or another.
Leigh Klotz: Why?
Steven Pemberton: For interoperability of styling.
Leigh Klotz: It doesn't help me much; there are so many problems with CSS in different implementations.
John Boyer: Can we work this out on the list today or tomorrow.
Mark Birbeck: Once you start defining one, why not all? I'm not sure we can do it in time. We discussed this on list and default values in the wiki.
John Boyer: This is a last-call comment for this property.
Mark Birbeck: For me, I'd say sorry we agree we want default styles but we need lots of them, not just for one element.
John Boyer: We already agreed to do it. Is inline really the right thing for group/switch/repeat.
Leigh Klotz: If it's the default, we have it for all elements, and there's always going to be a different use case for each, and we've already decided, then there's no reason to switch from what we've decided.
Nick van: Can we make it so that it decides by the container?
Steven Pemberton: That's the host language that decides block or inline.
Mark Birbeck: That's ....
Nick van: If you want it styled in block or div, why's that not legal?
Mark Birbeck: Context isn't relevant.
John Boyer: So I suppose I can proceed with inline for everything as we resolved and if that proves to be a problem I'm sure we'll hear about it.
Leigh Klotz: Sounds good to me. We already resolved it, it's just a default, it's always wrong for somebody.

* Need report of disposition of LC comments

John Boyer: How do we need this?
Steven Pemberton: You ask Shane nicely.
Nick van: [irc] shouldn't we first update the system?
John Boyer: I'll make a preliminary report and link it in.

* Issue 139

John Boyer: Erik, did you see the text about Issue 139?
Erik Bruchez: I'll try to do it.
John Boyer: Let's take it offline today. Something fast and easy would be great.
Erik Bruchez: I'll let you know.

* IRC Minutes


* Meeting Ends