W3C Forms teleconference April 30, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Mark Birbeck, x-port.net
Roger Pérez, SATEC
Uli Lissé, DreamLabs
Keith Wells, IBM
Leigh Klotz, Xerox (minutes)

* Agenda


* Previous Minutes

* Upcoming telecons

John Boyer: Next week, Nick is chairing. I'll be providing Nick the materials for the agenda, which he will make.

* Next FtF (June 9-12, Amsterdam)


John Boyer: We claim it's June 9-12.
Leigh Klotz: The page at http://www.w3.org/MarkUp/Forms/wiki/FtF_2008_06 said June 9-11 for a while but I checked with Steven.
John Boyer: He must have updated it. Also Erik wanted to know which days were Forms.
Charlie Wiecha: All of them, now.
John Boyer: Yes, no HTML days.

* Rich Web Application Backplane

http://lists.w3.org/Archives/Public/public-forms/2008Apr/0113.html http://www.w3.org/MarkUp/Forms/2006/backplane/

Charlie Wiecha: The kickoff call is the May 16th 10:00 AM eastern. Check with your AC rep to join.

* Action Item List:


John Boyer: I may be below the 10-item list, but Nick, please produce another copy with the changes from Charlie, Mark, and myself.
Leigh Klotz: I sent a message to the Felix Sasaki of ITS and asked if we were done, but got no response so I can't close that action yet.
John Boyer: I sent a note to PicoForms about the test suite; and Steven isn't here because of the Queen's Day holiday.

* Rename @resource?


John Boyer: There's a resource attribute and a resource child element of submission. It used to appear on the load action. This is a name conflict with RDFa. To the extent that we hope that XForms syntax can be used in XHTML without qualification, we need to address this.
Charlie Wiecha: It seems like RDFa has priority on the attribute. I agree with the thread.
John Boyer: I never did like the word "resource" for submission. It would have been best to have two types of action subelements; a local element with a value and global element with a container and handler.

Leigh Klotz: [irc] "An important principle of Web architecture is that all important resources be identifiable by URI. The finding discusses the relationship between the URI addressability of a resource and the choice between HTTP GET and POST methods with HTTP URIs. " http://www.w3.org/2001/tag/doc/whenToUseGet.html

John Boyer: The resource child attribute has a value. Could we have a local child action element that could have the value, and a global action with ev:event.
Mark Birbeck: You could, but the second couldn't appear as a child of submission, which is a shame, since you want action handlers on the child element. You can't differentiate on the basis of attributes in XML Schema. However, there is another possible longer term thing; when I was working on XML Events 2, I took the liberty of adding ev:action. Maybe we would consider deprecating our action instead.
Leigh Klotz: But that brings up the different namespaces again.
Mark Birbeck: XML Events also would be a module.
John Boyer: The action name has also always been, um, bad, as well. But what to we rename it to? It looks like action is a bit of a problem?
Leigh Klotz: I proposed the name resource from the TAG finding above so I think it's appropriate to say we can POST to a resource.
Mark Birbeck: The problem is that RDFa uses resource.
Leigh Klotz: That's OK to use it at a higher semantic level, but my point is that it's not inappropriate to be able to POST to a resource.
Mark Birbeck: RDFa's usage is broader.
John Boyer: Is there a conflict with submission?
Mark Birbeck: Here's an idea; maybe we just leverage it in a future version of RDFa, just as we have with img. We add a semantic interpretation to existing markup. If someone does rel="stylesheet", we say we can interpret that as an RDF statement saying that the document has a property of stylesheet, and here's the pointer. The first step with RDFa is to re-use attributes that you already use. So src on img is an existing HTML attribute which we give an RDF twist. If this resource attribute were already used in XForms and we came out with RDFa2, we'd go through the attributes and see if any had an obvious semantic meaning. We'd look at load/@resource, and say that it has a relationship of loads-external-program with this other document. Given that the RDF interpretation would then be the same as the RDFa interpretation, it might not be a problem at all.
John Boyer: That sounds good. And it's applicable for instance as well?
Leigh Klotz: If RDFa can be that flexible, that's a big point over XLink.
Mark Birbeck: RDFa 1 wouldn't do that; it would treat it as its own resource attribute, but I'm not sure that's a problem. It is unlikely that RDFa is going to go through life without resolving these issues.
John Boyer: So the discussion is that we leave the name for now?
Mark Birbeck: If someone came up with a brilliant new name, that would be great. So I'm wonder whether we should leave it. We should raise it with the RDFa group, but I reckon it would be OK, if we perform the thought experiment of what it would be in a year.
John Boyer: Can you do the action? Is it a last call comment?
Mark Birbeck: It wouldn't be a last-call comment, at least from me, to change the name for RDFa.
John Boyer: Not change the name, but just have the group consider the discussion?
Mark Birbeck: OK.

Action 2008-04-30.1: Mark Birbeck to raise issue of leaving XForms submission resource attribute alone and perhaps having RDFa document its semantics in a future version.

* Rename @target?


John Boyer: We gave Steven the action to come up with the name. I came across some language that said response might not be a bad name, but there was some discussion that it might. So let's discuss the name response. It would provide an XPath that says where, within the instance data, the submission response goes.
Erik Bruchez: I don't have a super-strong feeling. I was pointing that as Leigh had with resource, response in HTTP includes the status code and headers. We follow that concept in the XForms submit-done context information which allows getting the response status code.
John Boyer: The headers are response-headers.
Erik Bruchez: So technically it is the response-body not the response.
John Boyer: Any other names come to mind?
Charlie Wiecha: It's kind of ugly, but response-body or response-data would clarify it?
Leigh Klotz: Does it need to be clarified?
Charlie Wiecha: Do we need to add the specificity or do we tolerate the ambiguity for a simpler attribute name?
John Boyer: Following our chain of thinking here...in the submission, the problem is that we have replace=instance rather than replace=xpath. Then we have an instance attribute which takes an idref. I'm wondering again with a local element if it might not be possible to solve this with a child element of submission called instance. The other places where we've added child elements with value attributes, so we could use instance/@value to calculate the id of the instance; on the other hand, if we provide a child instance element with a ref, then we specify the node instance to replace.

<instance value="blah" />
gets the value of blah and uses as IDREF overload of instance attr but
<instance ref="blah" />
would instead overload by pointing to actual instance data
John Boyer: How does that sound, brainstorming?
Erik Bruchez: if we had response-body on xforms-submit-done, we could write <setvalue ev:event="xforms-submit-done" ref="/foo/bar" value="event(response-body)"/>. We have it for xforms-submit-error but not xforms-submit-done. So if our proposed solution is longer than this we aren't achieving anything great.
John Boyer: It seems <instance ref="blah" /> is shorter.
Erik Bruchez: So it seems that we want an attribute that invokes the response body or destination.
John Boyer: It's more the target; where does the result go?
Erik Bruchez: The submission element doesn't make clear what is related to the request vs what is related to the response.
Charlie Wiecha: The response element refers to neither, but to the place where the response goes. Not what's being selected from the response.
Erik Bruchez: The idea of target was to specify the destination.
Charlie Wiecha: Target was clearer. I like what Leigh just put in... <submission replace="instance" instance="instance(foo)/foo/bar" />
John Boyer: It's already an idref. We added it as an erratum to XForms 1.0.
Erik Bruchez: We could add an ugly attribute name.
Mark Birbeck: I agree on the amount of time we've spent on attribute names. Maybe coming up with patterns might save us time. Maybe instance-ref, instance-value. Then you can use it in different places; it's not lovely but it is consistent and easier for authors.
Charlie Wiecha: Steven would be bouncing off the walls on this point.
Leigh Klotz: Is it possible to do a union type of string and idref?
Mark Birbeck: An xpath expression?
Erik Bruchez: ...
John Boyer: Here's another possibility: in XForms 1.1, make it XPath; if you want an idref, use model="1.0" to force it.
Mark Birbeck: Then instance is the wrong place.
Leigh Klotz: <submission replace="instance(foo)/foo/bar" />
Mark Birbeck: But we don't have a response attribute now?
John Boyer: It's proposed but Erik said that there was ambiguity in the attribute name because it's just the response body. Charlie asked if we could live with that ambiguity.
Erik Bruchez: In xforms-submit-done and xforms-submit-error we have response-* because all those things are part of the response. It doesn't indicate that it's the response body; you can conclude that it's the response body because you can't easily format the response for storing in an instance, though you could imagine an XML response.
Mark Birbeck: But in terms of the current definition of submission, isn't the algorithm all about the returned body.
John Boyer: What about return?
Charlie Wiecha: It's not the target.
John Boyer: How about dest?
Leigh Klotz: desto?
Erik Bruchez: Other languages?
Leigh Klotz: atari? It means target.
Roger Pérez: destino is destination in Spanish
John Boyer: Maybe we should take this back off line. The -ref thing feels bad, unfortunately.
John Boyer: We said target would be used in lieu of the old instance attribute. So why not just redefine what mea means. That's the most radical propose.
Mark Birbeck: I wonder if we can go back to having two uses of the attribute interpreted in different ways.
Mark Birbeck: So why can't we have just a string?
Leigh Klotz: Or union of idref and string and leave disambiguation to a higher level on instance?
John Boyer: You have no way to tell which it is if it's replace="instance" unless you have a new keyword.
John Boyer: <submission replace="instance" target="xpath"
John Boyer: And replace="target" in the future for target=IDREF.
John Boyer: So we need to go back to Erik and see if you can live with the difference based on the value of replace?
Erik Bruchez: My initial objection was not a technical one; it's more of the author's point of view. An author with HTML experience will come to loading a new resource and expect target to mean something else.
John Boyer: replace=all is the default so if we're after streamlining, the behavior of replace=all in 1.2 could be further augmented by a target attribute. It's the most natural thing if the author already understands target idref.
Erik Bruchez: ...
John Boyer: There's no distinction between XPath expression and xsd:string in the schema; we could write it as union between idref and string though. We have no better way of schema validating XPath.
Leigh Klotz: We have avoided co-occurrence constraints but XML Schema is adding them as is RNG.
Mark Birbeck: So it's a string anyway.
Erik Bruchez: It's not as bad as I thought. We could use replace=text and have an XPath expression for the target.
John Boyer: The replace=target was proposed to replace a part of the document.
Mark Birbeck: Or a frame.
John Boyer: So you could use replace=all for that as it is the default.
Mark Birbeck: If we go for replacing a part of the document or frame, then we don't know if the person wants a new frame with x or the dom element with id=x so you'd use all for frame and target for document.
Leigh Klotz: Why can't you replace in the document with an XPath expression?
Mark Birbeck: That would be the doc() function to break out of that straight jacket.
John Boyer: We discussed before that our version of target would be an XPath expression; maybe around the same time as the document function.
Erik Bruchez: XPath 2.0 has doc() and XSLT has document('') so we could do the same in XForms.
John Boyer: So we could leave the target as XPath in that case; the streamlined syntax author might write an idref or _blank rather than an XPath. How would we deal with that?
John Boyer: Or a canonical XForms submission generated by form tags in simple syntax?
Leigh Klotz: "foo"
John Boyer: Or you need a document function. So we translate them into canonical XForms submission. We were concerned that there might be conflicts between the target attribute as an idref, but if we supported partial document replacement in the future, it would be more clever to use an XPath in the future?
Erik Bruchez: With replace=all?
Leigh Klotz: replace=some
John Boyer: They would write a form tag anyway.
Erik Bruchez: I think replace=all should use target as in html. If not, it doesn't solve the problem.
John Boyer: In xf:submission target could be an XPath but for streamlined syntax for HTML authors, form/@target etc could be an IDREF which we could convert in canonicalization to an appropriate document() XPath.
Erik Bruchez: I don't think it would be good because in HTML now it's not even an ID. It's something external, or a predefined name.
John Boyer: In the future, it could be something more like replace="frame" and in that case the frame could be whatever it is.
Charlie Wiecha: [irc] sounds like too much magic
Uli Lissé: [irc] why not rename replace="all" to replace="document"? when target is given, interpret it as IDREF, otherwise use document root.
Erik Bruchez: ...
John Boyer: Any objections to go back on the prior resolution and keep target as XForms 1.1, and we define it now as replace=instance or replace=text? In those cases, it's XPath.
Erik Bruchez: Since we've explained things for the future, I'm happy with keeping the target attribute.

Resolution 2008-04-30.1: We revoke our previous resolution and keep submission/@target as is, since we now understand that in the future we may take advantage of other attributes and XSLT 2.0 doc() function to refer to parts of the host document.

John Boyer: So no second last call!

* Submission "validation" issue


John Boyer: In XForms 1.0 SE the xforms-validate event was rewritten to exclude the validate attribute. So events are invalid with constraint or type (however specified) but there's no validity check on required-but-empty. Simultaneously, we redefined submission-validation to incorporate validity from the revalidate event and also accommodated the required-but-empty. So submission validation checks for required and stops if the node is empty. The problem Erik has raised is that we never said that the cumulative process is equal to submission validation, so there's an ambiguity with submission/@validate that it should turn off the required-but-empty condition checking. My proposed change would be editorial, that we retain the word "validate" but do a better job of defining submission validity. We need the proper rigorous definition.
Erik Bruchez: It seems to be the easiest fix; I've been confused for years. I've explained it to people, but I don't understand why the decision was made to say that required-but-invalid is a different concept, except for submission.
John Boyer: I wasn't happy with the choice either. If you include the required-but-empty condition you get what some thought was an unfavorable user experience from xforms-invalid event handlers. There's no way in CSS to handle the invalid displays only if it's not empty.
Charlie Wiecha: [irc] wasn't it for form startup?
Erik Bruchez: We had no MIP events sent when the page initialized though.
John Boyer: In XForms 1.0 we had no @if.
Erik Bruchez: We have extension context events. There's more that needs to be added if you want to cover the cases.
John Boyer: It's not too hard to get the value of the node using ".".
Erik Bruchez: You want context info for a single event handlers, not 400 of them.
John Boyer: I'm not sure we expose enough.
Erik Bruchez: We don't; you need more. ...
John Boyer: So you pointed out the processing model for the events has been clarified so the usability concern doesn't exist any more. So maybe we go back and fix validity.
Erik Bruchez: Yes, say invalid if required-but-empty and remove the text from submission, and we get a single idea of validity.
Leigh Klotz: Everybody wants non-empty leaf nodes not to be checked for validity if they are not required. The union types are a bit of a crock fix.
Erik Bruchez: I know what you mean, but it's the other side of the coin.
Leigh Klotz: We should consider them at the same time though if we're making changes on required-but-empty.
John Boyer: Some of the implementers aren't available. I think it was Chiba, but somebody said that they were hooking those events to CSS pseudo-properties and getting CSS for something being invalid when it was required-but-empty.
Erik Bruchez: My problem is that I couldn't style required-but-empty. We hack around to get it.
John Boyer: If you style for required and invalid....
Erik Bruchez: Required and empty doesn't. In CSS you can't get to the value of the node.
John Boyer: The objection was from a usability standpoint. If you had a big red X over the invalid things, then from the get-go the claim was you'd get big red X's.
Erik Bruchez: That's a use case that should be covered. But I'd like to mark the required fields when required but empty.
John Boyer: And your earlier point that events don't fire on startup anyway.
Erik Bruchez: We need a solution that addresses both cases.
John Boyer: This topic needs further work. It sounds like we need more discussion of this problem.

John Boyer: I won't be available for next week's call.

* IRC Log


* Meeting Ends