W3C Forms teleconference December 17, 2008

* Present

Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Paul Butcher, WebBackplane
Roger Pérez, SATEC

* Agenda


* Previous minutes

* Upcoming telecons

John Boyer: Our next call is January 7, 2009. Should it be 90 minutes?
Charlie Wiecha: I think so. We have a lot of modules.

* Rich Web Application Backplane

Charlie Wiecha: We're planning examples to develop for next year. Possibly an on-line, distributed application game with rich presentation and data, and diversity of client types (mobile, desktop). More a social distributed app (open social?) than a game.
John Boyer: Two people might be able to play each other.
Charlie Wiecha: Yes. That's better than a paper. The Ubiquity story applied beyond forms. Gregory made an analogy to the SVG-interest group, which is parallel to the spec-writing group and collects best practices. We thought we might spend time collecting jump-start info for an interest group.
John Boyer: And for a server?
Charlie Wiecha: We're still thinking of what the work product is. Right now it's just "what should we do?" showing cut-and-paste patterns.
Leigh Klotz: If you do it right there won't be any hosting; you could get the free stuff elsewhere and the rest will be small.
Charlie Wiecha: Yes, if it needs hosting other than the pages that's an issue.

* serialization=none in XForms 1.1


Leigh Klotz: I thought we fixed this years ago.
John Boyer: That was if the url string already had a question mark, we append a separator. But if you don't have any URL parameters to add because serialization=none, that didn't get accounted for. Is that problematic? We shouldn't add it. Is that OK?
Leigh Klotz: It seems like an editorial error.
John Boyer: Yes, it seemed like an oversight. Does it seem like it breaks anything?
Leigh Klotz: No.
John Boyer: Leaving it in breaks stuff.

Action 2008-12-17.1: John Boyer to fix section 11.9.1 to resolve http://lists.w3.org/Archives/Public/public-forms/2008Dec/0021.html to indicate we won't have the trailing ? or separator in the serialization=none case.

* XForms and ODF and XFDL

John Boyer: There's increasing interest in the way XForms manipulates data within a document vs. the need for archival records. A lot of the XForms actions (not all) are reflected in the underlying data, which is different from scripting, where you can add runtime data structures. In the past, this capability of JavaScript to create anything at anytime that's not in the document serialization has caused people to create archival versions of document formats in which the JavaScript has been turned off. In XForms, repeat and relevant are responsive to changes in the data. So we can preserve dynamism while still being archival because all the dynamism is reflected in the underlying data.
Leigh Klotz: You need a super-readonly though.
John Boyer: For purely archival purposes, all they're interested in is the that thing that gets stuck in the archive is a faithful rendition.
Leigh Klotz: I could see a "DOD record" MIP type as one of the use cases for extensible MIPs. So if you have a MIP that is a "DOD Record" attached to the data instances (and not the state) then you can inject them, and not worry about multiple MIP conflict. Archival data itself (POST and PUT) would remain immutable via servers-side configuration but this MIP extension would allow a record-aware processor to display the record data.
John Boyer: Yes. We currently just inject readonly at toplevel.
Leigh Klotz: You could style it and tell it's different, and not have to worry about conflict with readonly.
John Boyer: Perhaps we should solve the multiple-MIP issue.
Leigh Klotz: I wrote that up a long time ago; it's in the archives.

John Boyer: So back to the archival format issue, the only way we don't have perfection where the state is in the data is places such as setindex and toggle, managed by the UI but not reflected in the underlying data. The difficulty is that we haven't gone after this space before as a group, for documents that serve as archival records. Any thoughts on how we might proceed in that direction? Do you know of any other standardization body that might address this?
Leigh Klotz: Are you asking if we've looked at OASYS?
John Boyer: We don't talk much about ODF and XForms in the WG, now that you mention it. XForms models have been applied to ODF. Is there any interest in talking more about ODF?
Charlie Wiecha: That's a broader topic than archival. I'm confused about where the archival use case is coming from; ODF is another document format.
John Boyer: I've been seeing this issue with my customers; PDF for example is used in transaction systems because it's blessed as an archival format. We haven't done that with XForms.
Charlie Wiecha: The archival bit confuses me. XForms as content management (see the public list) has examples. http://lists.w3.org/Archives/Public/www-forms/2008Dec/0010.html
John Boyer: It would be preserving the XHTML that presented the UI as part of the archival record. They tend to pick PDF-based documents because they store the data and capture the screen.
Charlie Wiecha: We were talking about the backplane discussion yesterday; it's an integration exercise. It's hard to get the right people together.

Leigh Klotz: John, you're in a position to do a gap analysis. If it's just a few pieces of state such as setindex, and a few rules for preferring internal content, that may be easy. But if it's a multi-headed monster as Charlie says, we can't get involved.
Charlie Wiecha: John you should be able to do that fairly easily.
Leigh Klotz: Quite frequently, in the past, "dump memory" has been the answer, viz. Microsoft Word and Simonyi's memory structures.
John Boyer: ...
Charlie Wiecha: So the AJAX equivalent is to serialize the entire running state. That's messy.
Leigh Klotz: I can see Prototype.js doing that, serializing their state as JSON.
John Boyer: In the pure XForms case, the state is pretty clean modulo a few issues. The surrounding host language is the main issue.
Leigh Klotz: I'm all for you writing these down: setindex state, a MIP priority structure (which might be useful to us more generally), content inclusion. You can note the XHTML issues but they're out of our control.

* XForms 1.0 Basic

John Boyer: Now that the implementation report is available, is it possible?
Leigh Klotz: Do we know which exact version has passed? The test report is not 100% against the test suite.
John Boyer: http://www.w3.org/MarkUp/Forms/2008/XFormsBasicImplReport/BasicImplementationReport.html
John Boyer: http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/front_html/XF102edTestSuite.html

Leigh Klotz: There are many that have "testcase is wrong" for example.
John Boyer: The test case was missing a label; once they fixed that case it passed. But there are a few others which they said it failed because they don't support it. But the master document was an XForms 1.0 profile, and many other implementations pass the tests.
Leigh Klotz: One could argue that the failed tests are a symptom of removing XML Schema, even though we know it's not true.
John Boyer: You can check each specific case and see it's not true.

Leigh Klotz: I'd like to discuss this with the group more fully. Is it OK to publish as XForms 1.0 R2?
John Boyer: In the XForms 1.1 case, there is no XForms 1.0 Basic. It's just a conformance section. We could have been more generous in the conformance section in XForms 1.1. But given that XForms 1.1 contains XForms Basic, do we actually want to proceed with this document. How do you feel?
Leigh Klotz: I could see asking Steve Bratt to approve this at the same time as we take XForms 1.1 to the next level, since we can say that both XForms 1.0 and 1.1 both have support without XML Schema.
John Boyer: OK.

John Boyer: On XForms 1.1, we need more implementations.
Leigh Klotz: Maybe you can ask Joern van Rotterdam from the public-forms list to test.
John Boyer: We need two for each feature. They don't pass the test for the power() function. It's useful for doing financial calculations.
Leigh Klotz: It's probably a Mozilla structural issue for the need for a different super-reviewer for math functions.
John Boyer: Anyway we'll need two working implementations for the power function, among other things. Some of the tests are feature-level and test many actual different things. We have over 400 tests but they test 2000 things.

Action 2008-12-17.2: John Boyer to congratulate Joern van Rotterdam http://lists.w3.org/Archives/Public/www-forms/2008Dec/0010.html and ask for implementation report.

* Javascript implementation of replace all submissions

Paul Butcher: This is done. http://lists.w3.org/Archives/Public/www-forms/2008Dec/0012.html

* Problem with xf:copy and xf:delete

John Boyer: Leigh?
Leigh Klotz: I haven't done it yet.

* Review Data Island Module [discussion format]


Leigh Klotz: Charlie are you planning to add the JavaScript binding?
Charlie Wiecha: Yes.
Leigh Klotz: I wonder if the getAsJSON method could be only there, and not at all in the IDL. If the module is implemented in JavaScript, then it will simply fall out of the implementation anyway and the name is all we'd be specifying. A note about the error behavior (what to do if there is data loss in an XML to JSON conversion) is all we would need to resolve.
Charlie Wiecha: I'll take a look at that.

* XForms for HTML


John Boyer: We got publication approval for this document and it should be out tomorrow.
John Boyer: I found that we already had repeat attributes repeating their content, so it turned out the only error was in the example.

John Boyer: The other change was relevant to Leigh's question about JSON. In data submission http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#data-submission I added an extra paragraph (4th, section 6):

The element or tag that configures the submission shall be augmented with a method named processResult()

John Boyer: So if you make any changes you might look at this.
Charlie Wiecha: I'll take a look.
John Boyer: I didn't spell out the arguments. I did understand that in the case of JSON submissions, the parameter is clear. We need to talk about what to do with XML submissions here. But as a first draft we ought to have the name.
Charlie Wiecha: Is there interaction with the data instance module? It's JavaScript but it's more in the submission module.
John Boyer: Right.
Leigh Klotz: Same theme, but a different module.

Leigh Klotz: I don't understand "element or tag".
John Boyer: We've used that language elsewhere, so if it's wrong we'll correct it everywhere.

Leigh Klotz: And processResult is just a JavaScript way of doing xforms-submit-done?
John Boyer: No, it's for a different event that we haven't defined yet.
Leigh Klotz: What is the name?
John Boyer: You specify which element's processResult to call. When that script gets written into the page, that does it.
Leigh Klotz: I thought that you got the JSON data itself and processResult was a way of getting it in. prototype.js doesn't do this I think.
John Boyer: The server-side service generates a response which has the JSON object as the answer to the service surrounded by parentheses with your function name as the handler.
Leigh Klotz: I'm seeing a different split, but maybe I am looking at it with rose-colored glasses.
John Boyer: I thought this is what you had to do to make a JSON service work.

John Boyer: I noticed there were places where we didn't have function name consistency. getRuntimeElementById, processResult, getElementById, and then getvalue, setvalue, and so forth. For consistency it seemed better to make them all camel-cased. The markup is one thing, but the functions are another.

John Boyer: We have clearance of FPWD, which means it's clearance to be on the recommendation track, which is a good piece of progress for the working group.
Charlie Wiecha: There's also a new co-chair of HTML.

Leigh Klotz: http://intertwingly.net/blog/2008/12/15/Co-Chair-HTML-WG

John Boyer: Yes, the HTML WG charter does obligate them to make some comments.

* Custom MIPS

Nick van: I'm working on them, but not for the next two weeks.
John Boyer: ..
Nick van: It's a bit of a hack.
John Boyer: It's unique to bind. No other place attaches MIPs to nodes. We identify the node that it attaches the MIPs to. It's the initial context provided by context, not final. Every other element only talks about the in-scope evaluation context; they don't attach anything to it.
Nick van: But what if we need a second attribute like this and it won't be treated specially?
John Boyer: It's not special; it's setting the context. bind has separate behavior, attaching MIPs to nodes.
Nick van: You have to refer to the context by name in the bind module.
Leigh Klotz: Why?
John Boyer: There are two; the initial context has to be a defined concept because you have to have to say what the context is before.
Leigh Klotz: But that's not in bind.
John Boyer: The bind module will inherit it. In the binding attributes module it defines it.
Nick van: I don't need to make the definition in the bind module, only in the binding attributes module (not my module). That's fine then.
John Boyer: The term for where the MIP gets attached (with no nodeset) is the initial in-scope evaluation context.
Leigh Klotz: Does that make binds nest still? <bind nodeset="foo"><bind readonly="true()"/></bind>
John Boyer: Yes.

John Boyer: <bind nodeset="c"><bind context=".." calculate="a+b"/></bind>
John Boyer: That now works. It attaches to c but the context is the parent of c. The context is evaluated before the nodeset attribute.
Leigh Klotz: So what does this do? <bind nodeset="c" context=".." calculate="a+b" />
John Boyer: That sets the context first.
Leigh Klotz: So that's the same as this? <bind nodeset="../c" calculate="a+b" />
Nick van: If there are more siblings of c, it will go to the parent of the element.
John Boyer: We're talking about how bind works. So if I type this:

John Boyer: This might be an inner bind, but all the context does is to accept the in-scope evaluation context. The nodeset produced by the bind produces a set of nodes and that set of nodes is used to evaluate calculate. So when a nodeset attribute exists, it's taking control. <bind context=".." nodeset="c"><bind calculate="../a+../b"/></bind>
Nick van: <bind nodeset="c" context="../a" calculate="b + c"/> isn't the same as <bind nodeset="../a/c" calculate="b + c"/> if you have multiple a elements (I think)
John Boyer: The context attribute doesn't have any effect on evaluating the MIP expressions. The MIP expressions are evaluated relative to the nodeset. The context attribute expresses the first node rule, and that's consumed by the nodeset. It provides the subsequent evaluation context.
Nick van: In my example, context="../a" gives you the first a element. Then you evaluate c and you get all the c children. In the first example, you get all the c children of all a elements.
John Boyer: That's right.
Leigh Klotz: Leigh was asking if prepending context to nodeset was the same and it's not because the result of the expression retains only one node.
John Boyer: So there are two answers. It's not the same. And it's not the same because the calculate is relative to the nodeset. If the bind doesn't have a nodeset expressed, the calculate is relative to the in-scope evaluation context, which the context attribute affects.
Leigh Klotz: So look at context, then nodeset, then that's the new context, and calculate is evaluated with regard to that.
John Boyer: And then the answer of calculate goes back to the nodeset, one or more nodes. If there is no expressed nodeset, then we attach it to the last-expressed parent bind element. We don't attach MIPs to in-scope evaluation context nodes; we attach them to nodes specified by nodesets in binds.
John Boyer: This leads us back to the .. case. So you don't have to type ../a+../b. <bind nodeset="c"><bind context=".." calculate="a+b"/></bind> So the inner node sets the evaluation context and the outer nodeset sets the result.

Leigh Klotz: So in XForms 1.1 we have to use two binds, but in XForms for HTML, we say it's done as if it's done this way.
John Boyer: Right. So it is equal to <bind nodeset="c" calculate="../a+../b"/></bind>

Leigh Klotz: Do we have examples of this idiom in 1.1?
John Boyer: The context attribute on bind is a 1.2 feature.
Leigh Klotz: Ah, that's what was confusing me.

Nick van: <bind nodeset="c"><bind context="../line" calculate="sum(a)*b"/></bind> isn't the same as <bind nodeset="c"><bind calculate="sum(../line/a)*../line/b"/>
Nick van: We probably need to put a note in the spec saying to be careful.
John Boyer: Each inner bind receives a single node from the outer bind. A limitation of the context attribute is that you lose the position and size.
Nick van: In the first example I posted, you will get the sum of all a elements of the first line. In the second you'll get all lines.
John Boyer: Can you put it in email? It looks like an author issue.
Leigh Klotz: I think it's a tricky author issue.
Nick van: It's not just a common prefix elimination. You can't do it in all cases. If there are two nodes at the common point then it's not the same.
Leigh Klotz: So the result of Nick's calculation changes because when he moves the common prefix to the context, so the simple explanation that context can be used to reduce common prefixes is simplistic.
John Boyer: So you have to write a more complex expression.
Leigh Klotz: I'm worried about changes to existing expressions that work.
John Boyer: Which you can't because there is no context attribute in 1.1 anyway.
John Boyer: But first-node-rule, interesting point.

* Next Meeting January 7, 2009

* IRC Log


* Meeting Ends