W3C Forms teleconference September 10, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
Kenneth Sklander, PicoForms
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Paul Butcher, x-port.net
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C (Chair)
Keith Wells, IBM
Uli Lissé, DreamLabs [late]

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2008Sep/0001.html

* Previous minutes

* Administration of Wiki upgrade

Steven Pemberton: Our wiki is being migrated to MediaWiki. It's OK that the old Wiki is not being migrated, right? Nick and Leigh should check. Nick's not here.
Leigh Klotz: If I don't know what's there and it's member only then we don't need it.

* Announcement of Concentre XForms

http://concentre.zensoluciones.com/examples/yahoo_search.html

Steven Pemberton: It seems to work somewhat.
Charlie Wiecha: He seems to have a different approach from Ubiquity. It doesn't seem to be a scripted definition of each element, but a transcoding into JavaScript. It would be nice to have more focus on Ubiquity but it's a different approach.
Leigh Klotz: It's a separate effort and having someone work on one thing doesn't keep people from working on another.

Next FtF (October 15-16 Virtual, Oct. 20-21 Cannes)

Steven Pemberton: Please register; so far only four.
Charlie Wiecha: The hotel deadline has been extended.

* XML Base Comments

http://lists.w3.org/Archives/Public/public-forms/2008Sep/0012 http://lists.w3.org/Archives/Public/public-forms/2008Sep/0013 http://lists.w3.org/Archives/Public/public-forms/2008Sep/0014 http://lists.w3.org/Archives/Public/public-forms/2008Sep/0015

Steven Pemberton: I think they've replied satisfactorily be referring to the XML language to decide what are URIs. I think we should be happy with that comment.. Right? Silence is content.
Steven Pemberton: Our next comment was that LEIRE were not XML compatible and they said they'd add a note. OK.
Steven Pemberton: The next comment is an explanation of where the change is being made, so that's satisfactory.
Steven Pemberton: I think the last one is based on a misunderstanding from our point of view. We asked why it was a PER because it looked like implementations would have to change. They replied that there is no normative change and only pointed to a different reference for LEIRE rather than describing it themselves. I personally think these replies are OK.
Steven Pemberton: Do we reply saying we are happy?

Action 2008-09-10.1: Steven Pemberton to reply to http://lists.w3.org/Archives/Public/public-forms/2008Sep/0012 0013 0014 0015 saying we are satisfied.

* XSD 1.1, Kenneth, Mark

http://lists.w3.org/Archives/Public/public-forms/2008Sep/0016 http://lists.w3.org/Archives/Public/public-forms/2008Sep/0019 http://lists.w3.org/Archives/Public/public-forms/2008Sep/0020

Kenneth Sklander: My conclusion is that we should move to XML Schema 1.1 at the same time as we move to XPath 2.0. We should be careful about the PSVI and XPath evaluation context, but those are just technical challenges.
Steven Pemberton: You don't think there are any comments?
Kenneth Sklander: I have two comments that I wrote in the mail. There is a mistake about digits and the other is that they asked for feedback on assertions on simple types. I think we should have them.
Steven Pemberton: The comment?
Kenneth Sklander: You can have infinite digits in a floating point number; they meant significant digits. If we allow assertions with simple times, as we have with bind/@constraint, it is pretty good. The assertions in XML Schema 1.1 don't allow reference to other documents, so we still need our bind.
Steven Pemberton: Do we have an opinion that assertions cannot apply to parents or siblings?
Kenneth Sklander: I think they can.
Steven Pemberton: On an element, the XPath may not refer to a parent or sibling of an element.
Leigh Klotz: Maybe it's for applying mapreduce to extremely large XML documents.
Kenneth Sklander: So if people want to do it they can do it with constraint. I don't know why they have it, I don't think we should complain about it.
Steven Pemberton: You can't say then that input is a child at any level of form.
Kenneth Sklander: You can.
Steven Pemberton: You have to have two content models.
Kenneth Sklander: They do it with "wire cuts"?. I don't think it's a problem for use in XForms, but maybe a problem for validating an XForms document.
Steven Pemberton: Anything in XForms could be in an instance.
Kenneth Sklander: And you can then use bind. So I think it's perfectly satisfactory.
Steven Pemberton: I have personally been asked our opinion of this feature.
Kenneth Sklander: Within a forms processor, there are other ways to do it.
Leigh Klotz: So we can say we're going to keep our bind attribute because it's more functional.
Steven Pemberton: Yes.
Kenneth Sklander: And it can do cross-document reference.
Steven Pemberton: Do we resolve this XSD when it is a specification?
Kenneth Sklander: We can't chose to before XPath 2.0. This will be in REC before we get 1.2 out. I don't think we can resolve before 2.0. Within our model, there will be two stages for XPath evaluation so there may be some things to think through, especially if we allow access to XPath MIP functions.
Steven Pemberton: Any other comments? Mark? Paul? He sent his review a couple of hours ago.
Paul Butcher: I don't know.
Steven Pemberton: I might be missing something.
Kenneth Sklander: He explicitly stated in his mail that he has no formal comments.
Steven Pemberton: So we just have your two comments.
Leigh Klotz: And the third comment that we will continue to use bind/@constraint for two reasons.
Steven Pemberton: Yes, not being able to refer to siblings.
Leigh Klotz: And other documents.

Action 2008-09-10.2: Steven Pemberton to reply to XML Schema 1.1 call for comments with two comments from http://lists.w3.org/Archives/Public/public-forms/2008Sep/0016 0019 0020 and with a note that we will continue to use bind/@constraint for two reasons: reference to parents and siblings and reference to other documents.

Uli Lissé: [joins]

* XForms 1.2 XPath Functions Module

http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/instance/xpathFunctions/index-all.html

Steven Pemberton: Have we discussed this.
Charlie Wiecha: Yes.
Leigh Klotz: Yes, we're going to break this up into 2.1, 2.2, 2.3 and 2.4 as separate documents.

* XForms 1.2 XPath Bind Module

http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html

Steven Pemberton: This is a review for structure and contents. It adds element bind and attribute bind. Nick has a question about where we resolve id references.
Paul Butcher: Should that be in the host document, or possibly in repeat where it becomes different from anything else? Possibly in switch though I'm not sure if that's strictly true. You can have multiple instances of the same id with repeated content, so you need a way of resolving it. So in repeat, the current index, or a descendent of the ancestor repeat.
Steven Pemberton: I wonder if we need to define it in two places, the general case and special treatment for repeat. Here we're talking about bind and bind is never the child of repeat.
Leigh Klotz: I agree, I don't think the id reference definition belongs here. And computed expression as well.
Steven Pemberton: Let me ask the implementors. Is there anything to be gained by using ID? What's the value if id being a built-in datatype of XML? Has it made life easier or harder? What if we'd defined something such as "name" or "identifier" and used that.
Paul Butcher: To be honest, we don't pay any attention to the type. We get it from the browser.
Leigh Klotz: So the browser is depending on the type.
Paul Butcher: True, yes.
Steven Pemberton: Then you don't use standard DOM access for IDs when you're using repeat?
Paul Butcher: That's true, for repeat. We maintain our own list.
Steven Pemberton: So we do need our own definition. I suppose we chose id because we intend XForms to be embedded in other languages and we want id to be used consistently across other documents.
Paul Butcher: As a loaded DOM, it behaves like an ID, in the sense that you should have one. Only in the live state does it become a different game. You can validate the document against the Schema, but in a live XForms document the treatment is different.
Steven Pemberton: So what answer do we give? Is there a mini-id module? Do we put it in toplevel? It needs to be involved with repeat? Is it two-stage, defined half somewhere else? Maybe we don't have a sold feeling for how the whole thing combines to be able to answer that yet. We'll have to ask whoever edits this.
Erik Bruchez: Up to 1.0 2nd edition, we did not explicitly mention "id": http://www.w3.org/TR/2006/REC-xforms-20060314/slice3.html#structure-attrs-common

Steven Pemberton: We had a reason for not doing it and we realized it was a mistake. We still had things which referred to ids. We still had it and had to resolve it.
Leigh Klotz: We had a conformance requirement that the host language provide one.
Steven Pemberton: Are we otherwise happy with this module?

Leigh Klotz: I note in a similar vein, this module defines "computed expression" but doesn't use it.
Steven Pemberton: I wonder why?
Leigh Klotz: Probably for MIPs but no MIPs are defined here.
Steven Pemberton: So what do you propose.
Leigh Klotz: So where do we put things that are defined in one place and used in another.
Steven Pemberton: We should pass that on to Nick.

* Review of Actions module

http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/instance/actions/index-all.html

Steven Pemberton: We have the same comment here for id and repeat.
Steven Pemberton: Should we use XML Events 2 or not? Otherwise, I think it's OK.
Charlie Wiecha: We said we'd still need this function as we are not yet going to XML Events 2 in 1.2.

* We should automate boolean-from-string() on the boolean MIPs (relevant, readonly, constraint)

http://lists.w3.org/Archives/Public/public-forms/2008Jun/0069.html http://lists.w3.org/Archives/Public/public-forms/2008Feb/0077.html

Leigh Klotz: I proposed this in 2003 or so and I'm glad to see it's acceptable.
Steven Pemberton: I don't remember why it was said to be impossible before. Leigh?
Leigh Klotz: It was because the XPath 1.0 Rec does not indicate a way to do this. I pointed out that every XPath engine I've seen lets you specify a return type, and from there it turned into a discussion of COTS.
Steven Pemberton: Paul?
Paul Butcher: Changing it now will break existing documents. In XPath, empty nodesets are false and everything else is true. boolean-from-string is the other way around, so that if true were the default return and false or 0 were false, then the automatic casting would work. But that requires changing the behavior of boolean-from-string, or having a special boolean-from-string semantics for this default casting.
Kenneth Sklander: It's a little more as it destroys the backward-compatibility of properties.
Paul Butcher: That's the kind of thing I'm getting at with boolean-from-string. An empty nodeset would remain false. Oh, I see, sorry.

Steven Pemberton: I do like the idea of casting strings, because some of the hardest to debug XForms have been where I thought I had a number and I didn't. Trying to work out wrong types is really hard.
Paul Butcher: I'm not sure how this would help. This is MIPs and not internal to XPath.

Steven Pemberton: I meant in MIPs, using strings. Lexically they were numbers. So my MIPs weren't working. Isn't that what you're suggesting here?
Paul Butcher: Here it's the string value "false." If your MIP returns the string "false" that's "true".
Steven Pemberton: You said it was a good idea.
Leigh Klotz: Originally when I proposed it, yes. Now I am willing to listen to arguments about backward compatibility.
Kenneth Sklander: If you want to use boolean-from-string, we have to redefine boolean-from-string. That will mean that boolean true or false MIPs would still work.
Paul Butcher: Except for "false"
Kenneth Sklander: Everything else we could retain by using a combination of boolean and boolean-from-string. If the string "false" becomes false.
Leigh Klotz: You could say that's breaking backwards compatibility but that is the case we're trying to fix.
Paul Butcher: If we were to use boolean-from-string as is, then any existence test would become false and that would become false.
Leigh Klotz: Right, I meant with the redefined boolean-from-string. If we start out trying to make string "false" mean boolean false, we can't then claim it's breaking backward compatibility.
Kenneth Sklander: We can just say that MIPs treat string "false" as false. They already treat 0 as false.
Leigh Klotz: That's more straightforward.
Steven Pemberton: Paul, are you OK with that?
Paul Butcher: Yes.
Leigh Klotz: Do we need to say something about 0?
Kenneth Sklander: We already say that because we refer to the XPath boolean function which treats the number zero as false. There is also NaN which is treated there as well so we don't need to say anything.
Steven Pemberton: Resolved?

Resolution 2008-09-10.1: For future versions, we change MIPs that accept boolean values to say that they use the XPath boolean function to convert the value to boolean, except if the value is the string "false" in which case we treat it as a boolean false.

* Validity notification on initial or hidden data

http://lists.w3.org/Archives/Public/www-forms/2008May/0015.html

Steven Pemberton: I'd say that we've struggled with use case 2 for a long time. I don't quite understand the proposed solution, though I recognize the use cases.

Paul Butcher: You could bind on the ancestor node and hide on invalid.
Steven Pemberton: That would require you to have control over the structure of the data.
Paul Butcher: Or that your form mirror the structure of the data.
Leigh Klotz: In my email client example, I also needed parallel structured data: checkboxes next to each email item, which aren't part of the item original data. It seems like a more general issue.
Steven Pemberton: I think we should discuss this at the F2F as we promised the wizard issue would be in a later version in XForms 1.0.

* IRC Log

http://www.w3.org/2008/09/10-forms-minutes.html

* Meeting Ends