W3C Forms teleconference January 19, 2011

* Present

Erik Bruchez, Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Philip Fennell, MarkLogic
Steven Pemberton CWI/W3C (chair)
Uli Lissé, DreamLabs

* Agenda


* Previous Minutes


* Action Items and Tracker


* XBL2

Steven Pemberton: I've received a note about XBL2 which we'll need to discuss.
Erik Bruchez: It seems there is serious activity going on with something similar to XBL; it's a JavaScript. One of the presenters is a CSS editor, Tab Atkins, for now works for Google. One of the topics is Web Components, but he didn't get to talk about it. Another guy who works for Google this week blogged about shadow DOM. I have a feeling that these guys, are working on something.
Uli Lissé: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
Uli Lissé: http://annevankesteren.nl/2011/01/xbl
Erik Bruchez: So I would be interested in developing on something that someone else develops, but I don't think we have enough bandwidth to develop. Maybe we can leverage the enthusiasm and excitement and make it or an extension compatible with XForms components.
Steven Pemberton: So you think it would be really good to have a spec but we shouldn't do it.
Erik Bruchez: We would need enough motivated people and we don't have the bandwidth.
John Boyer: I agree; it makes sense, but it's a bandwidth.
Leigh Klotz: I think the shadow DOM stuff we can use like HTC, and it's incredibly important for us and others to be able to use. But it won't have namespaces or other stuff we need to implement XForms components, so we still need to do something for components.
Erik Bruchez: The developers are Mozilla and all are 100% aware of XBL. They want to take what's been done with XBL2 and simplifying it and re-evaluating use cases, and get something that works with HTML5. There's momentum that seems to be happening. I don't think we can take XBL2 in parallel. What I can see as possible is making sure that what they are doing will work in an XHTML context or with namespaces, or if that's not happening, then saying with XForms, we need extra things (namespace-awareness). But I don't know what will be developed.
Leigh Klotz: We still need to do components and I don't think the HTML5 thing is going to produce something we can use to combine xf:input and xf:action and so on into widgets. So we could use Orbeon's XBL2 subset or not, but we need something.
Erik Bruchez: I'm not sure that's true. The use cases they have at http://wiki.whatwg.org/wiki/Component_Model_Use_Cases shows encapsulated widgets, sliders, tab views, etc. All those use cases might not be covered, but they are the same use cases we have in XForms. It's the same concepts in the XBL2 spec. I don't think that it's a given that what they come up with will be less useful than XBL2. XBL2 is abandoned.
Leigh Klotz: Using the same "WebBL" would make it difficult to have a single vocabulary for shadow DOM in the browser and also allow XForms namespace to markup.
Erik Bruchez: I think we should watch and see what they're doing. If it's essentially XBL2 but with some essential additions, I'd rather use that as a base than XBL2. If as an XForms implementor in JavaScript in the browser, if that model can be leveraged right of the way that's great, but I don't know. If it's not possible, I'd rather have a dialect of that rather than a dialect of something different. On the server you can implement XBL2, but you can also implements the web components thing; it should be about the same. The concern here is not to build on something that is known to be abandoned. Maybe what they're doing is very close, but we have to look at what's different.
Leigh Klotz: What if they remove namespace support and we can't bind to XForms elements?
Erik Bruchez: There's binding and styling; CSS supports namespaces. If they keep the XBL2 approach, as a template language, then CSS would support namespaces. If they don't, then we add that back in. It's an incremental change. We'd have to say we need incremental changes on top. The alternative would be to say that just because we need namespace support we need to define something completely different.
Leigh Klotz: Did you take a look at the spec that had namespace support removed/
Erik Bruchez: No.

Steven Pemberton: There may come a time where we need to decide. My answer should then be that we value a specification for interoperability, but the current group wouldn't have the bandwith, but they would be happy to have use cases covered.
Leigh Klotz: Rather than divergent specs as I suggested, we should follow Erik's lead and ask for extensions to the new WebBL that support out use cases, such as namespaces, and we can support the use case development. So if we can get that done, then we don't need a separate spec.
Steven Pemberton: I think we've discussed the issue to my satisfaction.

* Note on XForms 1.1 computation dependency definition. A counterexample.


John Boyer: We talked about this last week. The form has a simple data model with a few nodes and a couple of binds. If you run this in a processor that implements the XForms 1.1 definition of node-test references (and it doesn't get the leaf-node value), you notice the calculated values get out of sync in a fairly ridiculous way. Yes can be less than No, and you get Prevail. It always seems to be one step behind. The reason for this is that the element poll_result has attributes, and the way the referencing system works with the node-test rule, bind to an attribute creates a reference to the parent element. That's inappropriate because the bind/@calculate doesn't refer to the poll_result element itself, only the attributes. If you follow the absolute letter of the spec, you wind up with a computational circular reference. It's clear to the reader that there is no circular reference, but by our definition of reference, there is. So it seems like a proof that the definition must be wrong.
John Boyer: When our implementation finds a circular reference, it doesn't do a compute exception; it does the best job it can, running the computs in order. It will at least calculate a result. As a result, we're seeing a wrong or out of sync answer rather than simply blowing up. Either result could be reasonable expected. The prior definition of reference for model bindings under XForms 1.0 (which was somewhat unclear about "dynamic") is not only must you match a node test, but the XPath has to grab the string value of the node. That fixes this problem: If you have an XPath expression, it's not just the node test that matches, but you also have to grab the string value of the node during the XPath evaluation; that's what counts as referring. Matching a node test...the second bind in this model has a calculate with choose(../@yes_count ...). The ../@yes_count grabs the string value of @yes_count, but that also counts as a reference on the parent node as well. That's what creates false references.
Leigh Klotz: Is this peculiar to attributes, or does the bad result generalize to children elements?
John Boyer: The peculiarity is that the calculate always refers to an endpoint and a calculate points to a leaf node. In order to generalize to problems other than attributes you'd have to be calculating a mixed-content thing. So If poll_result had yes_count and no_count then if poll_result itself were also used in the first bind to point to poll_result.
Leigh Klotz: Maybe we can focus on the attribute and leaf-node issue and make fewer changes that might produce problems.
John Boyer: It's the element poll_result is a complex type with simple content and we're saying that our reference mechanism breaks the correctness of calculating the simple content while also calculating the value of an attribute.
Erik Bruchez: I agree there's no circular reference. It's the text value of the elements. It's pretty straightforward.
Leigh Klotz: Is this about attributes and how calculate leaf nodes are determined?
John Boyer: No, it's about all model bind nodesets.
Leigh Klotz: Don't you have dynamic problems with rebuilds in the model, like <bind nodeset="a/b/c">?
John Boyer: No, you have to rebuild anyway when the number of "b" changes. If you do a/b[pred]/c then the c will change based on the predicate, but nothing in reference of node test fixes that anyway. We optimized an edge case of not having to do rebuilds as often, but in the process we broke complex type with simple content. One case got optimized at the cost of correctness in the other.
Leigh Klotz: What if we just said that the parent elements of attributes are not taken into account?
John Boyer: It would solve that but not the mixed-content case. I don't agree that that's circular reference. It's OK to reference the value of the first text node of a poll result in a complex type with two child elements. I would imagine it's a more marginal edge case, but it does exist and is another instance of incorrectness. It seems the better approach in the long-term is to be less precise abotu what referencing means and recognize an interop problem, and somehow relax the definition. For the short term, there may be rebuilds you need to do (per implementation) but in the long term, we should fix the fact that we need rebuilds.
Erik Bruchez: This example is interesting. With a completely different algorithm (static analysis), I could solve that problem and determine the order. Last week we said that determining the order would be hard with static analysis. But here we have a case where that would be possible. It would be a partial order in general, but here it is perfectly determinable. By static analysis I mean we can look at the expressions and determine the path touched in a hypothetical instance; you could look at it purely as a performance gain. I like the idea to relax the spec enough that we could choose to implement something in a completely different way yet still be compliant yet still do most of what the original spec wanted to do.
Steven Pemberton: [irc] +1 to that
John Boyer: I'm very concerned about that approach; I want to fix our algorithm so that it would generate the same order as the static analysis; the algorithm shouldn't be less smart. It would be better to have more power at runtime than you do in the designer. It's an orthogonal point. You don't implement the order thing, but all I want is to make that do as well as the static analysis.
Erik Bruchez: There are some things you can't do as easily as with static analysis without hooks into the XForms engine. As an example, for short-circuiting you have to run everything in the engine, but it's easier to do statically. Saxon XPath 2.0 already has the feature to analyze the expression and it returns the expression tree you walk statically and figure out the paths touched.
John Boyer: We're still talking about implementation choices. That same static analyze could be run at runtime. When we turn off short-circuiting, we run the static analyzer at runtime to find out what nodes are touched. I do think that the only place that runs into trouble is that a/b[pred]/c, would you say all a/b/c are being touched?
Erik Bruchez: Yes.
John Boyer: So you basically ignore predicates. That's another implementation issue.
Erik Bruchez: It's quite that simple. In XPath 2.0 you have quite complicated predicates. You have less of that issue if, for a given node you can determine the paths that the node will depend on. So it's a set of dependencies that might be at runtime bigger than the actual set of dependencies. Maybe I only depend on a/b[4]/c[5], but we don't know the shape of the instance so we don't know that statically. It's not identical to what you're doing.
John Boyer: You're describing a different way of analyzing the XPath, which we could do at design time or at runtime. You're using a means other than evaluation to calculate the dependency. Our opinions can converge there; I think we both agree that the spec is too specific on saying how the references are determined, which is orthogonal to how an XForms engine can determine the order to run the binds in. The higher level statement is that we want the system at runtime to figure out the order; if there's some means better than evaluation of the XPath, then great, but in an ideal world we wouldn't have a rebuild. In an ideal world, if the document order of the binds is "incorrect" the processor would just work that out.
Erik Bruchez: Right
John Boyer: Short term, we have a lot of implementations of XForms 1.1 that don't do what the spec says; Orbeon does one way for order, because of problems with the definition. We do another way in the model because of problems with the definition. I think that the genesis of the definition was because we were trying to unify definition of references in model-binding and UI-binding. I think the discussion started with repeat/input wanting numerous references for so we could allow UI binding dynamic predicates and the UI would know how to update. So that's a requirement and the spec is pretty good about not saying more about how to implement that. Implementors want some help described, so we tried to bend, I think incorrectly, the definition of referencing around the UI binding and it broke the model because the model still has rebuild in it.
Steven Pemberton: We need to conclude for today. It sounds like future work for getting rid of rebuild is valuable. It sounds like we need implementation advice along with the definition. The definition should be freestanding. What we do need is some erratum for this which we don't have time for today. If the erratum is loosening up the definition that sounds good to me. John, do you feel like you could find a definition for that?
John Boyer: I could.

Action 2011-01-19.1: John Boyer to propose erratum for loosening the definition for model nodeset references. http://www.w3.org/2011/01/19-forms-minutes.html#action01 NOT IN TRACKBOT YET

* IRC Minutes


* Meeting Ends