Alain Couthures, AgenceXML
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers [IRC]
Philip Fennell, MarkLogic
Steven Pemberton, CWI
Kurt Cagle, XMLToday
Uli Lissé, DreamLabs [joined late]
Erik Bruchez, Inventive Designers/Orbeon [joined late]
Steven Pemberton: Alain, Nick, and
I will be in Prague, and possibly Uli.
Leigh Klotz: betterForm said they will
announce a release at XML Prague.
Steven Pemberton: Yes, 4.0. They'll be
there?
Alain Couthures: I will be presenting
about eXistDB.
ACTION-1864 Steven Pemberton to announce BetterForm 4.0 on home page.
Leigh Klotz: Needs action item to implement resolution
ACTION-1865 Steven Pemberton to make https not optional in XForms 2.0.
Leigh Klotz: I wonder if we need to backfit this
<header><name>foo</name><value value="abc+3" /></header>
or
<header name="foo" value="{abc+3}" />
Kurt Cagle: There are no examples
of AVT usage in the host language yet.
Leigh Klotz: Yes, wherever we say that
we should support AVT in the host language we should say
that.
Kurt Cagle: Also, in those contexts,
we should specify that changes to the attribute values don't
propagate back to the model.
Leigh Klotz: They are like @value, not
@ref.
Steven Pemberton: Could you send a
note about that to the list?
Kurt Cagle: Sure.
Steven Pemberton: Also we need
examples.
Steven Pemberton: We designed the
submission element on top of xsl:output and took attributes from
there and added them to submission. XSLT2 added extra attributes
and we should decide if we want to include them or not. I don't
propose to add them, but we should examine them.
Leigh Klotz: @method is a
challenge.
Steven Pemberton: We didn't have it
the first time.
Leigh Klotz:
@method=xhtml does something different from xml but it
may be less important as time goes on.
Steven Pemberton: Right. Implementors
should let us know if we need them.
Leigh Klotz: We should point out ones
that are a problem, like method.
Steven Pemberton: What is
undeclare-prefixes? Is it like our includenamespaceprefixes?
Leigh Klotz: And name?
Philip Fennell: name lets you define
different outputs and use them from the main part of the
transform.
Steven Pemberton: Let's close this and
see if anyone wants to argue for adding any of these
attributes.
Steven Pemberton: This is a heads-up from Nick. I can't imagine it's a problem for anybody.
Steven Pemberton: We already decided not to do this.
Steven Pemberton: Can we do this
without Nick?
Leigh Klotz: I can see John wanting to
discuss this as well.
Steven Pemberton: This is a
heads-up from Nick. It would be good to have an example.
Leigh Klotz: What about using with an
id that is inside a repeat?
Uli Lissé: [joins]
Steven Pemberton: There has to be an
ancestor.
Leigh Klotz: Does binding
elements mean bind or xf:*/@ref elements?
Steven Pemberton: Right. I don't
know.
Leigh Klotz: setvalue out repeat
referring to one inside.
Steven Pemberton: No that's not
allowed because it's not an ancestor.
Leigh Klotz: Then in that case he must
xf:*/@ref because bind cannot be the ancestor of anything in the
UI.
Steven Pemberton: Right.
Steven Pemberton: It should be
answered by implementors. But he seems to think it's ok.
Leigh Klotz: The note looks OK to
me.
Steven Pemberton: Then we should
answer that we shouldn't limit it.
Steven Pemberton: Fixed a spelling error in the id anchor.
Leigh Klotz: I believe we came to a
consensus and John was happy that he could test to see if a node
had a parent, and if it didn't have a parent it was deleted.
Steven Pemberton: Yes, let's note that
and wait for Nick and John.
Steven Pemberton: Do we update this
from XSLT 1.0 to XSLT 2.0?
Leigh Klotz: If we're not going to add
any of hte XSLT 2.0 output attributes...
Steven Pemberton: I don't know enough
about the serialization used in 2.0 to say whether they've changed
anything other than responding to the new attributes.
Leigh Klotz: There's a whole spec on
XSLT serialization, second edition December 2010: http://www.w3.org/TR/xslt-xquery-serialization/
Steven Pemberton: And XQuery 1.0. That
looks like a good thing to read. It answers some of my questions. I
feel very inclined to reference this document.
Leigh Klotz: I think if do we should
add the attributes, since this document defines them.
Steven Pemberton: How do you
serialize, Alain? And Nick?
Alain Couthures: I use XSLT 1.0.
Steven Pemberton: Do you think we
should refer to XSLT 2.0?
Alain Couthures: I don't know
yet.
Steven Pemberton: Should we leave it
as an issue in the spec?
Leigh Klotz: If you implement only
XPath 1.0 then you're unlikely to implement XSLT 2.0
serialization.
Steven Pemberton: Quite. But it
doesn't sound like anybody has strong opinions so I'd call it out
in the spec, as an editorial point.
Leigh Klotz: That sounds great.
ACTION-1866 Steven Pemberton to Add XForms 2.0 editorial note, asking whether to use XSLT 2.0 serialization for submission http://lists.w3.org/Archives/Public/public-forms/2011Dec/0019.html
Erik Bruchez: We think the XForms
spec has too many requirements that terminate the XForms Processor,
in particular xforms-binding-exception and
xforms-compute-exception. We implemented something a little bit
different from what's in the spec. Consider a form that is first
shown to the user and will have interaction with the user; it's a
problematic behavior if the user performs an action that causes the
processor to stop working. There doesn't seem to be any provision
for recovering from that kind of error. Let's say you have an XPath
expression which either never ran, or an OK and at some point
causes a dynamic error. For example, in XPath 2, casting a value to
a type. A cast failure would cause a dynamic exception. It seems
this would fall into a compute exception. We don't have
xforms-compute-error or xforms-binding-error which are not fatal. I
think there should be an option for authors to recover. We
implemented a set of rules to follow when something goes wrong,
instead of stopping the engine. We don't do this when the form is
initially shown, since that's something we show the developer. But
later after user interaction, we try to recover. We dispatch events
and you could stop processing, but not necessarily. Let's say an
XPath expression fails at runtime. You take a default value for
that expression and instead bind that control to nothing and it
becomes non-relevant, then we dispatch an event to the application.
So if you have a bug and something bad happens, then the user could
possibly recover by saving data.
Erik Bruchez: At the very least, we
should give form authors the option to continue when something
happens, typically with XPath expressions and dynamic errors. We
implemented that and dispatch different events.
Leigh Klotz: If the exceptions aren't
caught does that turn into the spec error?
Erik Bruchez: No. We let you try to
continue after informing the user.
Steven Pemberton: These are the result
of an event, right? We submit an event whose default action is to
terminate? Couldn't you catch them?
Erik Bruchez: You cannot cancel this
event.
Steven Pemberton: Is that the
essential problem? Wouldn't that make it easier?
Erik Bruchez: It could be done; you
also have to say what happens. For example, < input ref="..."
and there is an error, you have to specify what happens to that
binding. And for output, itemset, etc. We said they resolve to an
empty nodeset or empty value.
Steven Pemberton: I think this is
good. I think it's an essential part of any mature application
system, that you can trap and try to recover from errors.
Leigh Klotz: I think we should discuss
it more. There's also saxon:try and xslt:try, in addition to the
compute exception.
Steven Pemberton: Yes, maybe a F2F
issue.