W3C Forms teleconference April 20, 2011

* Present

Alain Couthures, AgenceXML
Dan McCreary, Dan McCreary
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Erik Bruchez, Orbeon
Kurt Cagle, XMLToday

* Agenda


* Previous Minutes

* Mobile and Web Technologies in Social and Economic Development


Steven Pemberton: XForms is used by development agencies. They would like someone to talk in Dar es Salaam, Tanzania. June 4-5.

* XForms course 16-17 June 2011, San Carlos, California


Leigh Klotz: Can we put this on the news page?

ACTION-1792 Steven Pemberton to put this on the news page: http://lists.w3.org/Archives/Public/www-forms/2011Apr/0003.html

* An Introduction to XForms for Digital Humanists: How XForms Can Help Your Project


Alain Couthures: Another talk by Michael Sperberg-McQueen

ACTION-1793 Steven Pemberton to put this on the news page: https://dh2011.stanford.edu/?page_id=507

* normalizedString/input and string/textarea?


Alain Couthures: What is the right type for input or textarea? So why is string the default type for input?
Steven Pemberton: What breaks if the default type is a string if you bind input to it?
Alain Couthures: A textarea control. I cannot differentiate them by type. If I look at type of data, if string, it should be textarea to correctly edit it, so everything should be a textarea, that's the problem. If it's a normalized string...
Steven Pemberton: If the default type were normalized string then you couldn't bind a textarea to it.
Alain Couthures: A textarea could edit, but it should be a string.
Steven Pemberton: The answer is that the default type is (a) the most general type and (b) the thing that matches what HTML does, so if from a lazy point of view if you put "message" as the name of the element bound to textarea, it would just work. So it's to make it the most general datatype. If you bind a textarea to a normalized string it breaks, but if you bind an input to a string, it doesn't break.
Alain Couthures: Yes.
Steven Pemberton: So what are you trying to do that this makes difficult?
Alain Couthures: I'd like to choose the control from the XML.
Steven Pemberton: You're generating the form? It's hard to automatically choose an input element if they don't choose a type?
Alain Couthures: Yes.
Steven Pemberton: I think, unless there are other answers, that this is unfortunate but true.
Erik Bruchez: I understand a bit of what you're saying. I didn't think about normalized string type, but I had in mind that normalize-space would merge spaces within the string but that's not the case. So if the default type is one that not everyone has heard about that could be a problem. Another thing is that if you look at an XML document, within an element without mixed content, by default you can have (almost) any string, so that would be a departure from the default content in XML. Are there other ways of achieving what you want to achieve?
Alain Couthures: I don't know what datatype I should use from XForms to say that I want a textarea instead?
Steven Pemberton: What about xml:space? You can't say it's "kept" though. There's no easy way to see from a document whether spacing in an element is kept or not. If it's automatically generated controls, then perhaps the presence of a newline would be enough to use textarea.
Alain Couthures: I'd like to use xsi:type or schema to say how to edit the data.
Erik Bruchez: The schema types are a horror. I like the idea that you could have a default mapping for one-line text and then define an input.
Leigh Klotz: You could define your own type using pattern.
Steven Pemberton: Or just use normalizedString for input and not for textarea.
Erik Bruchez: There's something I'm not getting yet. Is this generating a form with XSLT? If you have an XForms document you have to have either input or textarea; we don't have an XForms foo element.
Alain Couthures: I don't like the textarea control; we could just use input and use a type. So choosing a type for textarea for input automatically.
Erik Bruchez: Specifically, right now, do you have a concrete problem with a document and a schema and you want to produce a document?
Alain Couthures: I'm building an XML editor from an XML document that adapts to xsi:type, so why not for textarea.
Steven Pemberton: Really, what you need is to say on the element that you want spacing preserved.
Alain Couthures: Spacing editable.
Steven Pemberton: Yes, same thing. If it's normalized then the spacing isn't preserved. So you could say if it has xml:space="preserve" then you get textarea, otherwise you get input.
Alain Couthures: But that requires an extra attribute.
Leigh Klotz: The spec doesn't require much about textarea or input. Both say free-form data entry. But textarea says "intended for use in entering multiline content."
Steven Pemberton: You could edit an integer with textarea.
Erik Bruchez: I'm not sure there's anything we could change. A string could represent the input differently for normalized string. The drawback is that you'd have a page full of textareas.
Kurt Cagle: If you're using an xml:space attribute, it should be on the model element being referenced, not the control.
Steven Pemberton: Exactly, it has to be on the instance. We're thinking of a way for Alain to distinguish between strings where newlines are intended and where they are not.
Steven Pemberton: Is that enough of an answer for today?
Alain Couthures: Yes.

* Offline XML Editor Example


Alain Couthures: It's now possible to have an XML editor within a browser. Many things can be used to show what XForms can do. I would like to implement EXI as well.
Steven Pemberton: Does it deal with mixed content?
Alain Couthures: No, I haven't tried. The first version, doesn't let you add or delete nodes, only change values.
Steven Pemberton: But it's completely generic?
Alain Couthures: Yes.
Steven Pemberton: I see you save to file://. Does that give you a dialog?
Alain Couthures: Yes. That's what I implemented in XSLTForms.
Steven Pemberton: So you always get a dialog.
Alain Couthures: For security reasons, I think it's required.
Steven Pemberton: Which version of XSLTForms does it work with?
Alain Couthures: The current beta version.
Steven Pemberton: So no question, just a request for feedback.

* XForms Templates


Steven Pemberton: From Daniele Ippoliti
Alain Couthures: For me it's about subforms.
Leigh Klotz: Or components.
Leigh Klotz: I nominate Erik to say he's got it implemented.
Erik Bruchez: Having a component you don't have to duplicate is a little better. It's a bit old but I can reply.
Steven Pemberton: Please do.

* label/@for, @appearance

Kurt Cagle: I have most of this up.
Steven Pemberton: Can we do this next week?
Kurt Cagle: Yes. Oh, I may not be here because of the MLUC.

* Tree Controls


Dan McCreary: I have done some work for this to gather links on the wiki. I found some residual artifacts from the tree controls in the past with sample markup, but I'll need more time. jQuery has a huge number of tree controls, but I'm looking for a 90/10 straw proposal.
Steven Pemberton: I recall X-Smiles had a tree extension. http://www.x-smiles.org/demo/xforms/folders/xhtmleditor.xhtml

Alain Couthures: Also ajaxForms has a tree control, but it's not in XSLTForms. http://ajaxforms.sourceforge.net/samples/addons.html#
Leigh Klotz: And Orbeon.
Erik Bruchez: It's very simple, not general-purpose. It's a way to represent a selection control. There's one for xf:select and one for xf:select1. http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls/selection-controls#TOC-Tree-appearance


Kurt Cagle: I've been reading the XBL spec. We're looking at a requirements document now.
Steven Pemberton: This Friday is HCG. I will report status.
Kurt Cagle: We're putting together a requirements document showing what's out there adn what's required and we can't say that we're going forward until we do that.

* XML/XHTML Task Force

Kurt Cagle: Norm Walsh put together a general summary of the use cases and published it a couple of weeks ago. I suspect this will be the result of the task force. Also, it looks like Sam Ruby and the chairs of the HTML Task Force have decided on preserving namespaces for RDFa.
Steven Pemberton: Yes, I'd heard that some decision was made with xmlns prefixes would be preserved, but I thought in the HTML version as well.
Kurt Cagle: Yes.
Steven Pemberton: There's someone working on an HTML version of RDFa and since you need prefixes for the values of rel and so on, there still needs to be a means for declaring prefixes. Which is in itself good news.

* Text Annotations


Dan McCreary: I looked at the four ways that people are adding rich text editors to XForms in the field. I looked at Orbeon, betterForms, eXSLTForms, and IBM Forms. Both Orbeon and betterForm use the mediaType in textarea, and both are server-side and use extra libraries. The IBM Forms product (and I have asked John Boyer for a definitive answer) have a text-type attribute "text/rtf" then they do display an RTF editor. The word RTF is often associated with non-XML representation of markup in word-processing, so we may have confusion about RTF tags or HTML annotations within a text area. We will have some interoperability issues at this point. I have not seen any efforts to address profiles of what tags should be accessible within the rich text editor. From what I understand, everything is custom. So I will continue to look at the other standards. So if it's a democracty mediatype="text/html" seems logical since it's what the most use. Also TEI has a mime type.
Nick van: We have a rich-text component in our implementation as well, and we use XSL-FO. We transform to HTML in a browser. For us it would be nice to plug in extra languages in the markup.
Steven Pemberton: So you want different mediatypes.
Nick van: So not just mediatype=text/html.
Steven Pemberton: I think Dan said he intended to look at the subset of HTML that people were doing now so we could evaluate what level.
Dan McCreary: That's on my Todo list. This area could have a huge impact. I'm trying to build a platform for future work and want to acknowledge existing production systems and the limited portability between them, and start small for future work.
Kurt Cagle: In addition to TEI, I think you should consider DITA as well. It's a large, active community needing an underlying rich markup capability. If we have rich context markup in a node, increasing it looks like that internal rich markup is something we need to look at.
Steven Pemberton: This is very closely related to Alain's generic XML editor. If we can find some way to merge the two into a generic solution, that would be our strongest card.
Kurt Cagle: content-editble in HTML5 will bring up the same issue. So we can have a block of content that effectively is open to interpretation of an particular annotation engine. One idea to think about (I saw this at Avalon) is a path attribute that finds a mapping within a content-editable region and a corresponding underlying XML representation to map between the two. A div or span, and a map to the external entity.

* IRC Minutes


* Meeting Ends