W3C Forms teleconference February 29, 2012

* Present

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

* Agenda


* Administration

Steven Pemberton: We have two weeks of Europeans having the call an hour earlier. I will send out mail.

* Reducing the amount of XForms markup by using more attributes instead of nested elements


John Boyer: Some consideration would have to be given to a value attribute as it does something else. It's hard to have @value contain an XPath expression sometimes and not others.
Leigh Klotz: How about <xf:item label="English">en</xf:item>
John Boyer: Yes.
Steven Pemberton: That would work.
Steven Pemberton: The reason we didn't have label as an attribute because certain scripts need child content. But as long as we keep label as an optional child element, they'll still be happy.
John Boyer: Why do they have a problem with it? Why can't they change the scripts?
Steven Pemberton: Some languages (not scripts) need languages. For example in Japanese.
John Boyer: So there are limits on the attribute value character space. OK.
Leigh Klotz: And how about item without a label, that just uses the label.
Steven Pemberton: If there's no label, the value and the label are the same thing?
John Boyer: That's pretty common; the 50 states and the two letter code.
Steven Pemberton: I have no objection.
Leigh Klotz: So we do this for item?
Steven Pemberton: I think he means everywhere.
Leigh Klotz: I'm not sure we can solve the value problem elsewhere with child content.
Steven Pemberton: Only item has value.
Leigh Klotz: But there may be others; what about help and hint?
Erik Bruchez: [joins]
Steven Pemberton: header, value, output, output, mediatype, others. So it looks ok at first.
Steven Pemberton: Erik, our conclusion is that it looks fine for label, but not for value, but we have another solution for value, but as Leigh pointed out we have to check that there are no other places where we'd want to use @value. The problem is that @value means something else.
Erik Bruchez: xf:output sets how @value works.
Leigh Klotz: A lot of other places have it too.
Alain Couthures: [returns]
Erik Bruchez: We have generic handling of the value attribute; we support it pretty much everywhere: label, help, hint, alert, value. We handle it consistently throughout containing an XPath expression. The spec doesn't support that; the rationale for us was Why Not? For a item/value/@ref element, there's a binding with @ref. That's why we support it everywhere. So you can use @value or @ref if it's a node.
Leigh Klotz: But in your example value is a constant not an XPath expression.
Erik Bruchez: Did you have a suggestion?
Leigh Klotz: Yes, use child text content, just like setvalue/@value or setvalue/text().
Erik Bruchez: In most forms we have indirections for I18N, and external itemsets. It would be good if we could reduce markup in those cases as well.
Erik Bruchez: So maybe something like this: <xf:input label-ref="...">
Erik Bruchez: Or do we just use avt: <xf:input label="{foobar}">.
Steven Pemberton: We might as well do that rather than add new attributes.
Erik Bruchez: Do others have that impression, that we require too much markup? Other XML vocabularies have not focused so much. People do seem to value conciseness, especially where there is no drawback. I think they wonder what we were thinking with all the keystrokes.
Leigh Klotz: John had the XForms Attributes project, technically still on the back burner.
John Boyer: It was easier to create attributes than to attach child content.

Steven Pemberton: Does anybody object to this suggested change? Let's accept it, modulo any surprises.
Leigh Klotz: We need the list, the prose change, and the schema change. I'll change the schema.
Leigh Klotz: Did we discuss help and hint? I usually use help as help/@src but what about hint?
Steven Pemberton: Does anyone propose this for hint?
Erik Bruchez: label, help, hint, alert
Steven Pemberton: Either child element or alert?
Erik Bruchez: Help happens to be longer, but since you can refer to a value by AVT. You can have plain-text help.
Leigh Klotz: Does alert need events?
Erik Bruchez: For us, we handle all four the same way at the control level. For example, hint can be placeholder with minimal appearance we talked about, or to display the hint next to the control.
Leigh Klotz: I was just asking if there are ev:* attributes on alert.
Steven Pemberton: No you don't need them.
Erik Bruchez: I don't know the original intent, but my understanding was that originally the CSS would be used to show it. But the CSS targets the markup we produce.
John Boyer: The event was message as if xforms-invalid event handler, but we removed that "as if" so that alert could be handled by CSS. So it's just metadata.
Leigh Klotz: So they're now pseudo-elements? label as an attribute.
John Boyer: I think.
Leigh Klotz: In the new proposal, input/@label would then produce a pseudo-element that would be styled. There's no longer an element.
Steven Pemberton: You'd have to introduce a new CSS selector.
Nick van: The old selectors would keep working if we just define it.
Leigh Klotz: So CSS xf|label { color: red; } not work anymore. So either a pseudo-element or go back to the class selectors from the Venice meeting.
Steven Pemberton: We need to decide how they are called.
Leigh Klotz: I thought it was decided in Venice.
Erik Bruchez: I think it was the south of France, and it was xf-label.
Steven Pemberton: Right. So styling has to be taken into account.

ACTION-1873 Steven Pemberton to analyze elements where @label @help @hint @alert and child text content for static value.

* XSLTForms Features


Alain Couthures: For XSLTForms 1.0 RC, I announced AVT support for HTML elements, JavaScript function calls from any XPath expression (and iText).
Alain Couthures: If the function is pure JavaScript it can be called with string parameters; it's quite elegant and powerful.
Steven Pemberton: There's no special markup?
Alain Couthures: It's XPath 1.0 with no prefix. It's interesting for authors.

Alain Couthures: iText is defined in another system, not pure XForms. I asked about it.
Steven Pemberton: It looks like there are multiple elements with the same ID.
Alain Couthures: That's the way it is now.

Leigh Klotz: We should also look at ITS and the HTML5 translation attribute. http://www.w3.org/TR/its/ http://www.w3.org/TR/its/
Steven Pemberton: Isn't that the other way around, to say that it doesn't need to be translated?

Steven Pemberton: In this example, it takes the language from the language of the page?
Alain Couthures: Yes but there's no way to choose it yet.
Steven Pemberton: I like this and I do this sort of thing myself using instances. The XPath expressions get very long.
Alain Couthures: It can be quite efficient. And it's readonly data.

Steven Pemberton: We could also create a spec for this.
Leigh Klotz: I think we wouldn't want all the text for all languages; the HTTP request should serve up the correct language. If there's just one language, there's no need to handle the ID problem, since there's only one ID.

Steven Pemberton: OK. Alain, this is experimental. What are you proposing?
Alain Couthures: The JavaScript extension is maybe not easy for Saxon. And iText is a good experiment, though not perfect.

* @iterate changes review


Leigh Klotz: I think we did this already.

* Made basic event properties available for the event() function


Steven Pemberton: Nick suggests we review this.
Nick van: If anyone has remarks, let me know.

* JSON/mediatypes/src/replace


Steven Pemberton: I'm sure we've done this.

* Expand data model of ref to an arbitrary sequence


Steven Pemberton: Isn't this @value and not @ref?
Leigh Klotz: This is just for repeat? How about itemset?
Nick van: Everything that can repeat or expects a string value.
John Boyer: I don't think this is a big expansion; repeat, itemset, and bind change from @nodeset to @ref. The element would decide how to process the result of the ref. The ship has already sailed on whether @ref is the appropriate word for a set of nodes. Now we're saying it can be things that don't happen to be nodes. We could just continue to call it @ref.
Steven Pemberton: So we make @ref a sequence everywhere?
John Boyer: We already did that to get rid of @nodeset. Nick is saying a sequence of nodes vs. a sequence of numbers doesn't matter.
Leigh Klotz: What happens if I call insert inside repeat?
Nick van: There isn't a node so you will get a binding exception.
John Boyer: In XPath 2.0 the starting context is a number.
Nick van: If the target of the insert is a number you can't.
Leigh Klotz: Orbeon has the xxf:repeat-nodeset function so you could insert into that but it is its own problem. I guess there is no longer a tight coupling between insert and repeat.
Erik Bruchez: Yes, you can only insert into a nodeset.
John Boyer: The form controls bind input or insert have to convert the data. The origin attribute of an insert could use the context and duplicate a 1 into data. The repeat is only giving the context. If you then refer to a non-node, we have that problem today.
Erik Bruchez: We consider binding to a number (atomic value) is relevant but readonly. So you could decide what to do here:
Erik Bruchez: <repeat ref="1 to 5"><input ref="instance()/foo[context()]"/></repeat>
Leigh Klotz: You said it was readonly.
John Boyer: You need a node for xf:input.
Erik Bruchez: It could; it depends on whether you say that the atomic value is non-relevant. Then repeat @ref wouldn't work.
John Boyer: No, that's the context. The element could decide.
Leigh Klotz: What about?
Erik Bruchez: <repeat ref="1 to 5"><output ref="instance()/foo[context()]"/></repeat>
Steven Pemberton: We need to talk more then.

* Next Meeting

Steven Pemberton: Normal time next week.

* IRC Minutes


* Meeting Ends