W3C Forms teleconference December 10, 2008

* Present

Charlie Wiecha, IBM
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Paul Butcher, WebBackplane
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers

* Agenda


* Previous minutes

* Missing Actions from Two Weeks Ago

Action 2008-12-10.1: John to fix typo in first step of submission (udate instead of update)

Action 2008-12-10.2: Paul to look at http://lists.w3.org/Archives/Public/www-forms/2008Nov/0008.html and send a reply

Action 2008-12-10.3: John to fix two examples in spec where event() is used in a ref and should be in a value attribute

* News items

John Boyer: I've added two items to the news section: the Lotus Forms (XForms-enabled product) and the Firefox implementation reports.

* Action items


John Boyer: It would help to get to the public list responses with some urgency this week.

* Javascript implementation of replace all submissions


John Boyer: public list response needed
Paul Butcher: I haven't done it yet.

* Problem with xf:copy and xf:delete


John Boyer: Leigh, public list response needed.
Leigh Klotz: I'll get to it today.

* The repeat-* attributes

http://lists.w3.org/Archives/Member/w3c-forms/2006OctDec/0232.html "? repeat-type="element|content""

John Boyer: We had a disconnect in understanding about whether these attributes repeat the element or its content. We now have time to get to consensus. The spec says that it repeats the content of the element. Some people believe it could repeat the content of the element. Perhaps we could have a new attribute that defaults to what the spec says now but give flexibility.
Charlie Wiecha: This sounds like Rube and Goldberg.
Paul Butcher: It's what we'd call "Heath Robinson."
Charlie Wiecha: I think we should make the decision and do what's right.
John Boyer: Offhand, does anybody know if the tests could distinguish between the two possibilities.
Keith Wells: I'll have to look at the test cases.
John Boyer: My conjecture is that there's no conformance issue.
Charlie Wiecha: Is this 1.1?
John Boyer: Once we decide we can decide that.
Charlie Wiecha: Is there any motivation to keep it the same? Technically?
Nick van: We use it the way it's specified and don't have any problems with it.
John Boyer: It's more philosophical view than a technical problem. Do attributes say something about the element or the content?
Nick van: Here's a test case that tests it and we'll need to change the test. http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt09/9.3/9.3.5/9.3.5.a.xhtml
John Boyer: There's some consistency; the repeat element repeats its content, so attributes should as well. The technical power comes from...you might have to attach them to a tbody to repeat the trs within it. If you could attach them to tbars you could create a repeating tr table with multiple repeats.
Charlie Wiecha: Maybe we extend the core repeat function and carry that attribute in. That sounds like a nice function to have...children of repeat element with subsets of repeated items.
Nick van: You can have multiple tbody in HTML.
Leigh Klotz: We verified that last time we discussed this. They can't nest.
John Boyer: I don't think I need that.
Nick van: You only need the tbody if you need to repeat the tr.
Charlie Wiecha: Leaving it on the parent works well with Dojo. There's a nice parallellism with the repeat element construct. My first inclination was to move it down but...
John Boyer: In XForms for HTML, I think it was necessary...really important to ensure that repetition happened on the element that had the named attribute.
John Boyer: http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#default-data-instance-startsize
John Boyer: The startsize attribute is what is repeated and it has the name.
Nick van: If you put startsize on the parent element (tbody) and you need to repeat two rows every time with a different name, then you can't accomplish it with this construct.
John Boyer: So you move them both to the same element?
Nick van: Why?
John Boyer: A form control is an element that has a name and startsize iterates a form control.
Nick van: Can't it the same?
John Boyer: It's not a big deal to move them both. If I put startsize on tbody and left name on tr, then startsize would be on an element which isn't a form control because it doesn't have a name. It makes it harder to specify what's going on. It would not be a big deal to move them both up though. We need to fix this pretty soon.
John Boyer: I haven't heard anything from our first public working draft request yet. I'll ping after the call.
John Boyer: Leaving it as repeating content seems the best idea.
Charlie Wiecha: Yes, I think so.
John Boyer: I didn't know or remember the multiple tbody.
John Boyer: We have test suite conformance, and we have a clear statement of current markup so I think.

Resolution 2008-12-10.1: We keep repeat-* attributes in XForms 1.1 the way that they are, as repeating content, as tested by http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt09/9.3/9.3.5/9.3.5.a.xhtml

* Future Version Isues

* Responding to Ian Hickson post


John Boyer: We don't have FPWD yet but I wonder if we're getting to the point where we can respond to this email. He's looking at Dave Raggett's Forms Lite work, which has similarities to what we're doing with XForms for HTML, and commenting that he doesn't see a need for declarative expressions containing JavaScript instead of XPath, which I think causes anapylactic shock.
Charlie Wiecha: JavaScript or XPath?
John Boyer: XPath. So if you can't track dependencies, he argues you don't need it.
John Boyer: ...
John Boyer: I think it comes down to calculate.
John Boyer: Do we need to respond now?
Charlie Wiecha: We're producing this document because our charter calls for it.
John Boyer: I think he's saying that one particular feature is not required; perhaps that's conformance feedback.
Charlie Wiecha: So make calculate optional?
John Boyer: Or recommended.
John Boyer: Here is the conformance: http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#conformance
John Boyer: It might be pared down to names, /, .., arithmetical operations, and operators. For example, no namespaces, no predicates. Doing full XPath would be recommended. So it profiles not just calculate, but constraint and others. We can say that the calculate attribute is in particular recommended (modularly). I'm not suggesting that we do that now but if we get feedback that would resolve it.
John Boyer: I don't think we need to respond, but we do need to consider the content. Do people feel we have considered its content?
John Boyer: What is our plan for XForms for HTML once we get it to FPWD? Is it parallel or do we work with the HTML5 group?
Leigh Klotz: I thought you said you were going to work with the Ubiquity implementation.
John Boyer: That's the short path forward past CR phase. I heard a rumor that they removed their repeating construct, for example, and might like this one.
Leigh Klotz: I think the route forward is to for IBM and Mark and Paul release Ubiquity as an end-run around HTML4 it's also an end-run around HTML5 so I see no reason to engage directly. We work in HCG through the charter and satisfy our objectives and if there is a task force we have materials on it. But our success with this document will come with adoption of the Ubiquity implementation as a peer to if not Dojo or Proptype then JQuery. And if there are enhancements to HTML5 that can be of general utility (in the "kitchen-sink" space) then they are likely to be useful to the other AJAX libraries as well and so they might as well hear it from there first.
Charlie Wiecha: That's more a WebApps issue.
Leigh Klotz: I mean things like keeping XML safe in the head and body without hacks, which are of general utility but likely to be heard more from other AJAX implementation groups.
Charlie Wiecha: Yes, there are some hacks that are done such as XML in script that we are doing that AJAX libraries are doing as well.
John Boyer: Maybe that's the approach them.
Charlie Wiecha: We should have a table of HTML5 features compared, though.
John Boyer: We need someone to do it.

Action 2008-12-10.4: John Boyer to find reviewer to do a feature comparison of HTML5 and XForms for HTML.

* Review Data Island Module [discussion format]

http://lists.w3.org/Archives/Public/public-forms/2008Dec/0015.html http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/instance/dataIsland/Data-Island-Module.html

Charlie Wiecha: I went back to the Wiki http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features and refactored this document. As a result, this is a skinny document that manages a loaded instance and a few bits of IDL for signalling lifecycle.

Charlie Wiecha: As Mark has asked, what are we calling this. Is it data island or data instance? And is it XML or more general? I've taken the point that the first generation is XML but there's an editor's note on the issue. We're doing refactoring here, not adding functionality, so we punt on the non-XML for now.
John Boyer: I agree. We can do extensions if we don't do anyting to limit ourselves. But it's modularization.
Charlie Wiecha: It's not clear what we'd do to preserve the future extensibility. Child elements of instance? Separate variables? It's not clear...I won't speculate here.
John Boyer: You can't tell this is XML until you exercise IDL that returns XML. If you call load with a URL, for example, you don't know what is at the other end of that URL.
Paul Butcher: Even then you don't have to have had XML. It just has to be XML-like. JSON, for example.
Leigh Klotz: JSON seems to have sprouted a lot of things they said they'd never do such as attributes. As far as XForms is concerned, ref, nodeset, and XPath, it's pretty close. They don't have PI's and comments but we pretty much ignore them.
Charlie Wiecha: Coercing everything into XML may not be useful.
Leigh Klotz: I think exposing the data island as JSON is one issue, and accepting JSON data and providing an InfoSet is another. They're separate issues with separate audiences. They're almost orthogonal, perhaps 80 degrees off. So we can probably more easily treat the wire serialization format JSON here and then leave the accessing the data as JSON to later. JSON in that sense is merely an API for XML, just like JDOM and XOM are better Java APIs for accessing XML than DOM is.
John Boyer: ... Serializing and converting may be expensive for the short term.
Leigh Klotz: What's the IDL?
Charlie Wiecha: getInstanceDocument, setInstanceDocument, and load.
Leigh Klotz: So you could just trivially support a DOM-based view via getInstanceDocument and allow the MIME type.
Charlie Wiecha: That's the MIME type argument.
Paul Butcher: You don't have to say it; you can just say that it can process other MIME types.
Leigh Klotz: I think it's trivial to say that we can load JSON and present it as DOM. It's harder to talk about the authoring issue of what do do with the data and use JSON or dot notation, and I claim that Prototype...
Charlie Wiecha: And E4X
Leigh Klotz: are ways of wrapping DOM with JSON and accessing it in JavaScript, so it's a separate problem.
Charlie Wiecha: That's a good breaking point between current and future features.

Charlie Wiecha: OK, next is name: XML Data Island or XML Data Instance.
John Boyer: We went with the Island name but Instance is what we use elsewhere.
Charlie Wiecha: Mark asks if we need a separate load. Isn't it the same as load in DOM2? I call this from the F2F. Do we need a separate event that says this data island is ready vs. any other object?
John Boyer: What if the data is specified internally? Does it still get the event?
Charlie Wiecha: It would seem to be inconsistent not to, but it also would be a degenerate case. Would a shadow repeat structure trigger a load event?
John Boyer: Would it show up with @src or @resource as well?
Charlie Wiecha: Would that influence the event we use?
John Boyer: Oh, we dispatch the event, I see.
Charlie Wiecha: Yes, @src or @resource, we still have to dispatch it. It seems Mark is saying it is analogous to any other synchronized remote resource.

Action 2008-12-10.5: Charlie Wiecha to recommend whether to use DOM2 load event or custom load event in XML Data Island Module.

Charlie Wiecha: The next issue is whether we want IDL or not. Perhaps we want language-specific versions either instead or as well.
Leigh Klotz: DOM provides Java bindings for example.
John Boyer: So it could be just an example.
Charlie Wiecha: Should it be normative?
Leigh Klotz: There's the W3C DOM package you can get for Java, the interfaces everyone uses. DOM Level 2 http://www.w3.org/TR/DOM-Level-2-Core/ has IDL, Java, and ECMAScript bindings.
Charlie Wiecha: I can explore this and develop a recommendation. Are we going to do this elsewhere?
Leigh Klotz: When you do the JavaScript binding you're going to quickly want the getAsJSON.
Charlie Wiecha: We don't have to cross that bridge yet.

Charlie Wiecha: Mark says that the document is loaded already so load is a misleading name. I don't think there's a lifecycle about traversing in an XForms container. I had imagined that someone using this module in isolation would have to exercise load. Does that make sense? I'd assumed it did, and that the model module would exercise the load.
Leigh Klotz: I don't see how you can be wrong on this, so either Mark will agree or there's something subtle I don't get.
John Boyer: Maybe it's a distinction between load and reset. That would be the state immediately after src and resource; it would use the cached copy.
Charlie Wiecha: I think we moved that out of this module and into model.
John Boyer: The model level would invoke this reset.
Leigh Klotz: I think we took the cache out of the lowest level to reduce its cost.
John Boyer: I remember.

Action 2008-12-10.6: Charlie Wiecha to note that DOM Level 2 http://www.w3.org/TR/DOM-Level-2-Core/ has IDL, Java, and ECMAScript bindings and decide appropriate course of action for Data Islands.

Charlie Wiecha: OK, I'll answer Mark.

Leigh Klotz: One more issue, if we allow remote load of XML and JSON and then we allow inline JSON we'll need a type attribute.
John Boyer: Charlie?
Charlie Wiecha: If I see inline JSON, that's consistent with the remote case.
Charlie Wiecha: So you're saying if we provide remote JSON, provide remote JSON. And if we provide local JSON we need a mime type?
Leigh Klotz: Yes.

Action 2008-12-10.7: Charlie Wiecha to propose a type attribute for XML Data Islands.

* IRC Minutes


* Meeting Ends