W3C Forms teleconference April 1, 2009

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Mark Birbeck, webBackplane
Paul Butcher, webBackplane
Uli Lissé, DreamLabs
Charlie Wiecha, IBM

* Agenda


* Previous minutes

* AC Meeting

Charlie Wiecha: Briefly, there was a panel discussion Monday morning to kick off the day. Monday was dedicated to the future of the browser, with the subtext being the future of HTML5 and other languages. The minutes are transcribed. It wasn't super controversional. The real substance of the discussion happened in the breakout sessions. In Tuesday we discussed the WGs. On Monday, there was a fair amount of detail on extensibility in HTML and in particular distributed extensibility, groups other than the HTML WG needing the ability to have a well-architected, well-implemented mechanism for adding extensibility to the language. We differentiated two kinds of extensibility: language extensibility (new markup without runtime support in the core browser; no new media, or SIF), including Ubiquity XForms and ODF, which define behaviors without new plugins or deployable components at the browser level. That distinction was quite eye-opening at the meeting and then fairly well endorsed in the breakout as a useful distinction. The consensus was that distributed extensibility was quired, and the debate was about mechanism. There was a distinction between XHTML and HTML; there was not 100% consensus but there was some agreement that to the degree that a WG has an ownership for an XML language it ought be using the XML mechanism for extensibility, i.e. namespaces, and that if they did not it was a contradiction in the ownership. There wasn't 100% agreement but that ought to apply use of namespaces in XHTML. Steven also discussed namespaces in HTML, but that wasn't broadly agreed, so the question is still open for exactly how to handle distributed extensibility in HTML. The comments are in the minutes.
John Boyer: That particular point is an interesting one; they say on the one hand if you own an XML vocabulary you should advocate namespaces. On the other hand they say they want the HTML to have ownership of the "HTML Namespace" so that XHTML is the HTML serialization of XHTML, so in that sense the HTML WG has ownership of the XML vocabulary. That leads to the logical conclusion due to Steven that namespaces should be used in HTML.
Charlie Wiecha: I don't know the history, but that last step wasn't accepted. That leaves open the door that there would be non-namespaced mechanisms in HTML.
Charlie Wiecha: Another point is that extensibility is a requirement and unrecognized elements should be tolerated, the concern was that the HTML WG effort for fixup algorithms for non-WF HTML shouldn't interfere with the straight-through parsing of the DOM. So the Ubiquity mechanism depends on the DOM internalization. This also got put on the table as part of the extensibility mechanism: do no harm to elements you don't recognize.
Charlie Wiecha: So we came back on Tuesday to discuss the XHTML and XHTML2 WG relationship. We took forms of the table for that discussion; that was my suggestion. There had been a fairly good email discussion before the AC meeting in response to the straw-man discussion about the design-time rebranding for XForms, showing it is used in ODF and other places. Also, I wanted to avoid deep-ending and wanted to discuss the deeper convergence issues before forms. That was good. It helped keeping the discussion at a broader level. Steven itemized the non-forms technologies: RDFa, XML Events, M12N. That was an eye-opener to other people at the breakout.
Charlie Wiecha: At the end, there was a challenge to Steven and Sam Ruby to come up with a more detailed technical analysis of the connection points on a merged activity. They said this didn't mean ending the XHTML2 WG, but then a new group to have some scope of work reflective of the analysis that Steven and Sam are undertaking. See Sam Ruby's history of the evolution of HTML and where he would see things go in the future. He seems to say that we need a new direction. He points to Ubiquity XForms as an example of the kind of thing that needs to be supported.
Charlie Wiecha: The room was guardedly optimistic. The different use cases and requirements were not necessarily an issue.

Charlie Wiecha: For my opinions on forms, I believe we have a two-by-two design space and we haven't covered all four. The two axes are MVC or not, and the other is XML or HTML markup format. We've covered XML+MVC with classic XForms. We haven't covered HTML+MVC, with data models, instances, bind, etc. It may be grandfathering those elements into HTML, but it might be more complicated. We need to describe this.
John Boyer: I had thought that was the ramp-up trajectory X4H was on. With attributes only, it's generating a data model. The spec itself has space for your own model and instances.
Charlie Wiecha: We ought to have a valid design point of HTML with XForms elements.
John Boyer: That's what XHTML2 is doing, chameleoning in the elements.
Charlie Wiecha: The point here is that it's done in a non-XML language.
John Boyer: The tag grammar is slightly different. For bind, submission, what's the difference syntactically? How does it change?
Charlie Wiecha: I don't know, but I want to describe the requirement. The excution will have subtleties I don't yet appreciate.
John Boyer: The "certain things" that end tags have is the bucket we want to add to. Otherwise there's really not much difference.
Charlie Wiecha: We were chartered to have architectural consistency. We ought to be consistent across the design space and haven't evangelized that.

John Boyer: Is that the full story?
Charlie Wiecha: Yes. I was happy about the AC endorsement of full extensibility.

John Boyer: http://www.w3.org/MarkUp/Forms/specs/XForms1.2/XFormsForHTML/index-all.html#form-containment
John Boyer: This says that a form can contain an XForms model using the model element.
Charlie Wiecha: That's wrong; we don't need the xf: namespace. Moreover, why shouldn't HTML have a model element.
John Boyer: Maybe we need to tweak the X4H document.
Charlie Wiecha: That's an execution issue. Or maybe we need to go back to the core XForms document.
John Boyer: We need WF only in the instance data.
Charlie Wiecha: It's more about the patterns than the transport of the XML language. We need to reflect that more strongly in our spec. Tongue in cheek, I say there's only two things wrong with the name XForms: one is the X and the other is the Forms.
John Boyer: On the X piece, it's clear that what we have is a general MVC-connector architecture; there can be alternate syntactic means of activating it.
Charlie Wiecha: ...
John Boyer: We make client-side interactive technologies, produce implementation reports, follow the W3C process, etc.

* Next FtF


Charlie Wiecha: I was able to book small rooms at the London location; I have 8 and 10.
John Boyer: Sounds like a go for London then.
Paul Butcher: Mark was talking about a company near us that hosts user groups and potentially would run a mini-conference for users if anyone's interested in pursuing it.
John Boyer: That was one of the potential rationales of holding it on London.
Paul Butcher: Mark is investigating.
John Boyer: Thursday and Friday?
Paul Butcher: Something like that.
John Boyer: Is the hosting IBM and webBackplane?
Charlie Wiecha: One of us must attend to interface with the building people.
John Boyer: We are also slated to have a virtual day on Thursday June 4th.
John Boyer: Who is the audience?
Paul Butcher: People who want to use XForms.
John Boyer: OK, so that's a customer event.

John Boyer: When might we know if that's going to happen?
Paul Butcher: I'll find out when I next speak to Mark.

* Rich Web Applications Backplane

Charlie Wiecha: I posted some notes about things needed for the SVG controls. A space to construct visualizations, such as for SVG, related to an underlying repeat. The work in Ubiquity XForms is a preview. I have three SVG things: the pie chart, Line Graphs in SVG (from Apple Developer Conference), and a Circular Histogram from Yorktown.
Charlie Wiecha: Jack is pushing on his SMIL controller. We thought about using that for a Wizard to control the SVG.
Charlie Wiecha: Phillipe had a demo at the AC meeting with Firefox 3.1 with video.
Charlie Wiecha: ... bindings vs the elements ...

John Boyer: Everybody here understands that forms are dynamic client-side applications, not static pizza forms. We mean a generalized data-collection application with binding to presentations such as the circular histogram you mentioned.
Charlie Wiecha: There's probably a layered story in the Backplane. You could use binding, or you could deal with the binding yourself. It's a little tricky to make sure the repeat worked properly in Ubiquity XForms implementation. We might talk about how to make decorated repeats.
John Boyer: Is there room for using the repeat attributes.
Charlie Wiecha: That's an interesting attack.
John Boyer: The flaw in that might be that they aren't there. It might help. There is some scant commentary in the XForms spec about using these UI-binding attributes on other elements.
Charlie Wiecha: The roles helped. One role was value, the other label.
Leigh Klotz: What's the markup look like?
Charlie Wiecha: http://ubiquity-xforms.googlecode.com/svn-history/r2616/changes/cwiecha@gmail.com/svg-custom-repeat/samples/svg/svg-loan.xhtml

        <xforms:repeat nodeset="wedges/w" role="output-proportional">
                <xforms:output ref="num" role="value"></xforms:output>
                <xforms:output ref="text" role="label"></xforms:output>

John Boyer: Are these pie charts and line graphs predominantly outputs?
Charlie Wiecha: I looked at itemset vs. repeat. Currently they're just outputs.
John Boyer: That's commensurate with video output.

* Submission as multipart/form-data


Erik Bruchez: We need to know if the value is submitted as a part, or if it's just the data. The spec says two things. For one, it says that the node xs:anyURI and xs:base64Binary should be serialized as a part. The other says it's only when done by an upload control. I can see how it's useful that nodes of type xs:anyURI not populated by an upload serialized as a part, but there may be some useful values.
Leigh Klotz: I wrote it.. it's a magic step. It's not supposed to be settable, just the upload can set it.
Erik Bruchez: So you have be able to copy over the value and use a special value?
Leigh Klotz: You use a special non-readable model item property.
John Boyer: When you do an upload, it seems like whatever file has been selected needs to be moved to a magic internal area. The URL shouldn't be equal to the exact pathname of the file that's being uploaded.
Leigh Klotz: I don't think it does that in serialization.
John Boyer: It doesn't say what to do.
Leigh Klotz: The serialization is specified by the MIME RFCs. The xml-base type version is one way, but the CID: URI schema works better and that's what we show in examples.
Erik Bruchez: It is necessary for the client to transfer the file to the server. In a server-side implementation we copy the file over to the server. And we put the URI in the temporary file.
Leigh Klotz: It's unspecified what the URI is during processing. I don't think it causes interop problems.
John Boyer: You can submit afterwards in a different submission format.
Erik Bruchez: IE6 uses the full path; Firefox uses the last part only.
Leigh Klotz: I think these are security concerns and we ask vendors to address security concerns and give them implementation freedom. We recommend via example CID and used to specify it but a public comment asked us not to profile the MIME RFC. We might need to add a note saying to pay attention to security concerns when an upload is applied to a node which is later serialized with urlencoded (i.e. in GET).
John Boyer: I don't know that the spec needs to change, but we may need to ...
Erik Bruchez: Do you put the uploaded file as base64Binary or update the attachment? if you do a submission again, then those elements are not sent as separate parts.
Leigh Klotz: The unchanged URIs will be kept the same and so the server should understand what HTTP urls are just like it understands CIDs.
John Boyer: As written the 5th bullet point doesn't suggest an upload, just an xsd:anyURI.

Erik Bruchez: I'm not sure what we want by the behavior.
John Boyer: What does the test case do?
John Boyer: There's what the spec says and what it perhaps should say.
Leigh Klotz: It says "Element nodes of any data type populated by upload" and "of any data type" means "regardless of data type."
John Boyer: That's what you think it means but it's not clear.
Leigh Klotz: OK. When we hear Erik's use case we can decide how to fix it.

Erik Bruchez: I'd like to have control over serialization I can't in 1.1.
Leigh Klotz: I believe implementations should use a hidden MIP and it sounds reasonable to expose it.
Erik Bruchez: Even if you clarify the language, what happens if you use xf:insert to move the node. What happens if you use setvalue? It it moved? Is it checked?
John Boyer: I'd say it's not kept. setvalue and insert move data around. They don't have any magic data nor do they move it.
John Boyer: We can take the requirement for how to broaden the way to specify multiple parts and it could be 1.2 or beyond. For 1.1, we can be clearer in the spec that they only thing that creates a part is something populated by an upload.
Leigh Klotz: setvalue should clear the hidden data, and leave the text.
John Boyer: Yes.
Leigh Klotz: If you do repeat and a series of nodes and upload bound to them, an insert should produce a new row but not copy the uploaded data, just the URI text.
John Boyer: Yes.
Leigh Klotz: So anything else such as the use case for downloading a profile with embedded photo and then uploading it again (GET/PUT in the REST sense) is not possible in XForms 1.1 series, though we can imagine it for the future.
Erik Bruchez: OK.
John Boyer: So we can make the language clearer and keep the requirement for later.

Action 2009-04-1.1: John Boyer to clarify http://www.w3.org/TR/xforms/#serialize-multipart and http://www.w3.org/TR/xforms/#serialize-multipart to show that for upload content serialization to occur, the node must have been directly populated by an upload; subsequent setvalue operations will negate the upload; a node copied by some operation such as insert or select/copy will not copy the uploaded content, only the lexical value of the node.

Resolution 2009-04-1.1: We agree to consider control of serialization of attachments in a future version of XForms.

* IRC Log


* Meeting Ends