W3C Forms teleconference December 21, 2011

* Present

Alain Couthures, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox (chair/minutes)
Nick van den Bleeken, Inventive Designers
Kurt Cagle, XMLToday
Erik Bruchez, Inventive Designers

* Agenda


* AVTs in XForms


Nick van: Being able to use AVT in host-language markup is handy. For example, if you use HTML you can use it in class attributes. Adding to XForms is a bit more complex because we already have an AVT concept, with child elements that can have the value attribute for where we have static attributes. I asked about adding AVT to host language only, but Steven pointed out xf:input/@class, so you want the AVT for consistency.
Nick van: So I started thinking about supporting AVT in XForms, and came up with a list of places.
John Boyer: Historically, I remember this discussion in 1.1, separating into host-language and XForms features. I thought it included host-language elements and host attributes such as class for host-language. The XForms spec isn't there to define the host language, but can have a note suggesting using a language like SHOULD (perhaps too strong), maybe "or encouraged", for non-normative use. So that host language implementations are encouraged to allow AVTs. Possibly, some normative text saying how XForms processors should provide some way to have host processors access the UI binding (right?) mechanism. You want something to trigger the AVT. We're calling the host language AVT. So the host language knows when it will happen. I don't think we ever got that language into the spec but it seemed like a good idea and there weren't a lot of impediments.
John Boyer: Your point about exceptional places within XForms is where the bigger body of work or concern was in the 1.1 timeframe. Everything is open for discussion is in the new spec. The AVT discussion was in CR. When we have normative control over features, we have a complex lifecycle and want to make some considerations. For example, what if I put an AVT in the XPath in a bind.
Nick van: It's already an XPath expression there.
John Boyer: You have to say where it's not allowed.
Leigh Klotz: Nick says "that don't contain an XPath expression."
John Boyer: It seems like we'd have to create a long list. It seems like people wouldn't know why it doesn't work. A compute exception or binding exception would be useful.
Leigh Klotz: What about Erik's model in Orbeon of implementing AVTs as variables? I think he said everything you can do with a AVT you can do with a variable.
John Boyer: I think he said once you have variables you may not need AVT.
Nick van: They interpose a child variable. Then class becomes a variable which is calculated.
Leigh Klotz: Then you still have the lifetime issues John brought up.
Nick van: Yes. And it's also done on submission and it's evaluated when needed. That's why it would be nice to add AVT. Almost everywhere we have a child element that it makes sense but with AVT we can support it everywhere.
Leigh Klotz: I certainly think it's desirable.
John Boyer: We'll have to say there are places where it doesn't work, but maybe we'll say here are the places where it does work. As we add more features to the language we will then make the decision about the exception vs inclusion list.
Nick van: The exception list is quite long, to be safe. Some can already be changed, for example bind/@type. But when the binding changes you can already changes the type. Incremental and appearance might not be a big deal as the control can bind to another node.
John Boyer: Yes, I remember.
Leigh Klotz: Chiba and I think Mozilla had that bug for a while, for example with repeat/input and type binding not changing, but that was 5 years ago and now fixed.
John Boyer: I think we'll need the inclusion/exclusion list anyway. We can change the type in the schema from enumeration to enumeration or squiggly string.
Nick van: That's a downside that we need to change the schema.
Leigh Klotz: If you don't have a squiggly brace in there, then all bets are still on.
John Boyer: Yes, but we have to change them. And the spec too. It's a lot of work, but not a technical limitation.
Nick van: It depends; do we change the datatype or is AVT resolution done before the value is checked?
Leigh Klotz: You really need to validate the source file.
Nick van: Right, but the host language wouldn't allow curly-braces, so we replace them before giving it to the host language. We could do the same in XForms and say AVTs are expanded.
Leigh Klotz: I think we should say that the AVTs are expanded before but the schema has to change.
Nick van: Yes, right, but we can have an AVT section. It's a separate module that ads AVT support to the host language and to XForms.
Leigh Klotz: Where do you put the list? On the attribute or in the module?
Nick van: It's easier in the module.
John Boyer: In the content model tables we'd have to change the column header to say post-AVT resolution.
Leigh Klotz: I like the modularity but I'm worried about the exception list. I wonder if we can define "dynamism" somehow and then allow attributes to opt out in their content models.
John Boyer: Right, define the dynamic feature and say that it doesn't participate in the dynamic feature. We have a couple of modules separated out or in the XPath module I don't know. We do still have to say something in the core spec about whether they participate.
Leigh Klotz: And other modules.
John Boyer: We have all our modules in one spec, except for one right now. It would be light work to separate submission and action into its own spec. But even looking at it from a chapter perspective, it should be contained. Attributes should have dynamic stuff unless otherwise stated.
Leigh Klotz: So we just come up with a name for it.
Leigh Klotz: I'm happy if we can say attributes support dynamic evaluation, and then we have the AVT chapter that says it provides dynamic evaluation. And the content model doesn't implement the syntax of the AVT.
John Boyer: The content model tables would have a column header that says the content model presented is post-dynamic-evaluation, which would then suggest it applies. Then only specific attributes say they don't support it.

Leigh Klotz: So Nick I guess we're hearing that we'd like to have do/don't support dynamic value in the various chapters of the spec, and not in the AVT chapter itself. For HTML integration as with @class, that would be in the XHTML+XForms integration, for which we have a schema already.
Nick van: That seems to require a lot of spec changes.
John Boyer: In http://www.w3.org/TR/xforms11/#submit the current column header is "Overview of Attributes" and could say "Overview of Attributes and Their Content (after dynamic evaluation)". Unless we expect multiple ways to add dynamic evaluation.
Nick van: Well someone may want to factor out AVTs.
John Boyer: Then "after AVT evaluation." But the reader in the chapter is clued in that xsd:boolean or xsd:NMTOKEN is subject to AVT. If there is a specific entry that doesn't support it, we could say it doesn't support AVT where the type is. Does that make sense.
Nick van: Yes, it does for me.
Leigh Klotz: So it's assumed that if it's not an XPath expression, if it's a constant, then it supports it.

Nick van: Do we deprecate the child elements or just keep them?
John Boyer: It's just a matter of reference. Do you deprecate the old feature? It's still supported. My gut feel is deprecate. It's not 1.2 anymore. We're going to 2.0.

Erik Bruchez: [joins]
John Boyer: For example, submission has child elements that would go away.
Leigh Klotz: Be deprecated.

Leigh Klotz: In XSLT, notice users get confused about where they can use AVT and have to learn about xsl:value-of and xsl:copy-of. We don't have those, and xf:output isn't that either. The only area that comes to mind is xf:setvalue with child content, but we don't support that.
John Boyer: Say you have an XML-encoded string that is an xf:action or xf:input and you put a squiggly-brace inside a repeat.
Leigh Klotz: Mark Birbeck would do that for sure.
John Boyer: That might not work but I can see it trying. It fails the sniff test. We said AVT are available in attributes.
Leigh Klotz: Right, but what's our answer when people want dynamic content?
Nick van: We already have @value.
Leigh Klotz: What about label and setvalue?
John Boyer: label and setvalue both have ref and label has output. But I see Leigh's point.
Leigh Klotz: I think that we need to have an answer and we're happy giving that answer on the mailing list.
Leigh Klotz: So <h1>{$title}</h1> is <h1:<xf:output select="title" /></h1>
Nick van: Our answer is context dependent but context is everywhere.
John Boyer: That's host-language dependent. Does it encourage use of AVT in content as well?
Nick van: I would propose attributes only. Curly braces aren't used that much in attributes but they are in text.
John Boyer: I have a host language that's not HTML and the presentation is controlled by XML elements. On one hand I'd benefit from being able to say that AVT works on content but on the other hand, I use a compute attribute to do that. I can envision a host language without a compute attribute. If there comes a point where you're forced to add an attribute you might just add a value attribute.
Leigh Klotz: I'm satisfied that we have an answer for any confusion that might arise and it's dependent on context.
John Boyer: We're encouraging the use of attributes and not in element content, or using context-specific alternatives such as output.
Nick van: Then the host language should be able to exclude where it is used.
John Boyer: Absolutely. The encouragement should be non-normative. There might be a separate note. For the specific language XHTML, here's how to use AVTs.
Leigh Klotz: We've got a schema for that, we just don't have the document.
John Boyer: Sounds like a possibly separate action item for a host-language basis. I'd describe it for XFDL, where it works, etc. Having guidance from the spec would help, identifying what kind of XPath binding is being created. Unless someone has an object, I think it should be a UI binding, and that determines when it is identified. But maybe it's not.
Leigh Klotz: I think it's very close to xf:output/@value.
John Boyer: Yes, it is. We're saying you can use an AVT in host language in place of output since you can't put output in an attribute, and it makes it clear when it's going to happen. It will provide some basis for interoperability across same host languages.

Resolution 2011-12-21.1: We add AVT to XForms 2.0 defined in a separate module as equivalent in evaluation to xf:output/@value for host languages. For XForms attributes, we change the column heading for the content model to say that value types are post-AVT evaluation, and we specifically mark attributes that do not participate at their point of definition.

Nick van: I had the action item for adding AVT to the spec. For the HTML note I'm not that interested.

ACTION-1849 Nick van den Bleeken to add AVT to XForms 2.0.

ACTION-1850 Leigh Klotz to add AVT to XHTML+XForms schema.

ACTION-1851 Leigh Klotz to add AVT to XHTML+XForms Note.

ACTION-1852 Leigh Klotz to add AVT to XForms 2.0 schema.

* Next Meeting

We'll try for December 28.

* IRC Minutes


* Meeting Ends