Alain Couthures, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox (chair/minutes)
Nick van den Bleeken, Inventive Designers
Kurt Cagle, XMLToday
Erik Bruchez, Inventive Designers
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.