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
Steven Pemberton: We have two weeks of Europeans having the call an hour earlier. I will send out mail.
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.
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.
Leigh Klotz: I think we did this already.
Steven Pemberton: Nick suggests we
review this.
Nick van: If anyone has remarks, let
me know.
Steven Pemberton: I'm sure we've done this.
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.
Steven Pemberton: Normal time next week.