Steven Pemberton, CWI (chair)
Philip Fennell, MarkLogic
Uli Lissé, DreamLabs
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Erik Bruchez, Orbeon [arrived late]
Steven Pemberton: I think we should
take him up on the propagation="stop" test offer.
Steven Pemberton: These are tests for
XML Events.
Steven Pemberton: "the schema allows
event attributes on the model element." Yes.
Steven Pemberton: "We interpreted this
test to mean that the defaultAction for the custom-event was to be
cancelled on the model element." Hmmm.
Leigh Klotz: The test has
ev:defaultAction="cancel" on it.
Steven Pemberton: Yes, but as he
rightly says, a custom event doesn't have a default action. So you
can only use inbuilt events.
Nick van: It's a bit strange that the
event listener is registered on the model; why should the action
get executed?
Steven Pemberton: It's dipatched to
the model; there's a listener on the model for that event.
Nick van: If you remove the
defaultAction="cancel" why should the message be shown? There is no
event handler on the action.
Steven Pemberton: Right. This example
needs work.
Nick van: There should be a custom
event listener on the action but the observer should be the
model.
Steven Pemberton: It is by default as
it's a child of the model. All the same, cancelling it isn't going
to work because it doesn't have a default action; the default
action happens after all handlers are done. A handler is allowed to
switch off the default action if it wants to block it for whatever
reason.
Nick van: But not for custom
events.
Steven Pemberton: As there isn't one.
You have to use an event with a default action.
Nick van: This is testing cancel of
custom events. If I define an event with a default action couldn't
I have one?
Steven Pemberton: An implementation
could have a default action. But an event dreamed up in the form
itself doesn't.
Nick van: So I don't think you can
test it.
Steven Pemberton: If this is testing
for cancel, you can cancel a non-custom event.
Nick van: This is testing cancel of
custom events.
Leigh Klotz: 10.8.f tests cancel of
predefined events.
Nick van: If there is no default
action and you cancel it there is nothing to do.
Leigh Klotz: It did everything it was
supposed to, which is nothing.
Steven Pemberton: "we assumed that any
handler for the given event is to be cancelled on the current
element.b" That's wrong, but our test is wrong as well.
Steven Pemberton: This test is
harmless but useless.
Leigh Klotz: Perhaps we should put in
a comment that says that if custom-event had a defaultAction in the
implementation it would be cancelled.
Nick van: It's wrong as is because you
won't see the custom-event message. But really you won't see it
because nobody's listening.
Leigh Klotz: It's like those things in
the garden that scare away tigers.
Steven Pemberton: We can either
deprecate the test or fix it. We can't leave it as is.
Leigh Klotz: The easiest fix is to put
in a listener on action and change the text to say that you must
see the message and must not see defaultAction execution of
custom-event.
Steven Pemberton: Do we want to do
that then? I can do it.
Nick van: I have it open and can do it
now. I will move the event to the action and say you must see the
custom event, but you must not see...
Steven Pemberton: Any custom-event
defaultAction.
Steven Pemberton: I'll answer the
message.
Leigh Klotz: This is an XML Events
conformance issue and doesn't affect XForms 1.1 conformance.
ACTION-1844 Steven Pemberton to reply to http://lists.w3.org/Archives/Public/public-forms/2011Nov/0019.html saying the test is being rewritten, and to accept the offer of new tests.
Resolution 2011-11-16.1: In test 10.8.f, when you activate the Fire Custom Event trigger you must see a custom-event message. If an implementation has a default action for the custom event you must not see the effect of the default action.
Leigh Klotz: Are we dropping this
in favor of subforms? The proposal from betterForm. Alain is
implementing subforms in XSLTForms as well. http://www.w3.org/MarkUp/Forms/wiki/Load_Embedding
model/@src is static and comes with the problems of having to deal
with conflicts. load embedding comes with the same cost but
provides dynamic control.
Erik Bruchez: [joins]
Nick van: This allows you to define a
point where you can insert another form? Is there any communication
between the master form and the child form?
Leigh Klotz: At the editorial meeting
in Palo Alto we said events work and it's just as if the model and
UI were already there, so whatever communications you would use in
that case works.
Nick van: What about initialization
events?
Leigh Klotz: We didn't say anything.
We'll see what betterForm and XSLTForms do.
Nick van: What about repeat?
Leigh Klotz: Good issue. Why don't you
add them to the wiki page?
Leigh Klotz: I believe we can wait for
Alain's proposal which is simpler and then we will have somethng to
compare with the betterForm proposal.
Resolution 2011-11-16.2: We drop the model/@src proposal in favor of load embedding and await a second implementation to compare.
Erik Bruchez: Currently, we don't
say we need to dispatch UI events during initial creation ofUI. I
think that is a problem, but if were to say that xforms-select must
be dispatched for cases, we should also handle it for other UI
events.
Leigh Klotz: Somehow this just led us
to xxf:dialog-select.
Erik Bruchez: xforms-select is
dispatched in switch/case and also item in an itemset, in two
cases. So the dialog select is just a selection control.
Leigh Klotz: Does xxf:dialog-select
have semantics or is it just presentation?
Erik Bruchez: It's just an appearance
but not done using @appearance.
Steven Pemberton: What is separator=",
"? It's an extension?
Erik Bruchez: Yes, it's an XBL
component, so it does what you want.
Leigh Klotz: OK, so it's just a
different presentation. Somehow we got to this from the original
message.
Steven Pemberton: Does separator
affect parsing?
Erik Bruchez: If you select two and
seven, when you say confirm, it says how it's represented in the
page.
Steven Pemberton: When the instance is
initialized, and this control is set up, does it use that separator
to identify the initial values.
Erik Bruchez: No, this is related only
to the label.
Leigh Klotz: So this is the format
string for how this control looks on the page when the dialog is
closed.
Steven Pemberton: I see. One of the
less handy things about our select is that we can't handle values
with spaces in them. But if you had a separator.
Leigh Klotz: I bet if we had XPath 2
we could do that with a sequence, but it wouldn't be free.
Erik Bruchez: I don't think XPath 2
would help storing. You could use a regexp or anything to create an
itemset. But you don't have control over storing back. You'd have
to specify something at the XForms level. It's been suggested; many
controls might benefit from having a general mechanism to convert
to instance value. encode/decode or format, for all controls. Then
you could encode the values when storing them. I think that's
something needed.
Leigh Klotz: That's what I meant.
Don't do it with some attribute language, but instead use XPath 2.
And then the extra work is writing the converter that goes
back.
Erik Bruchez: Certainly we shouldn't
assume XPath 1. It's 12 years old.
Leigh Klotz: I think we should write
this up. A double-direction encode/decode filter pair of XPath
expressions.
Steven Pemberton: For lists?
Leigh Klotz: As Erik says, for all
controls. Erik do you have a proposal?
Erik Bruchez:
http://wiki.orbeon.com/forms/doc/developer-guide/xforms-other-extensions#TOC-Default-formatting
Erik Bruchez: Right now it only works
on output.
Erik Bruchez: <xforms:input
format="expr1" unformat="expr2">
Erik Bruchez: I think we have
something further on this
Steven Pemberton: XML has lexical and
value spaces.
Leigh Klotz: This seems like a middle
level.
Erik Bruchez: We say that the control
itself can deal with space-separated tokens. The idea would be to
say that the instance has space-separated tokens and a
bi-directional converter. Many times users ask for non-ISO date
formats in the instance. So I could imagine a similar conversion
system. It's like a data layer.
Leigh Klotz: Exactly. It sounds like a
different layer.
Erik Bruchez: Then you have
presentation to the user; there's parsing of the values. We have
this for date and time; you can enter dates in various configurable
formats: you can type "today". Then we produce the ISO date as the
output. Ideally XSLT 2, format strings, etc.
Steven Pemberton: Sounds like a good
discussion point for a potential features.
Leigh Klotz: It sounds like two
different features here.
Erik Bruchez: I think that's
right.
Leigh Klotz: There's two and from the
instance data, and to and from the presentation.
Erik Bruchez:
https://github.com/orbeon/orbeon-forms/blob/master/src/java/org/orbeon/oxf/xforms/control/controls/XFormsInputControl.java#L51
Steven Pemberton: What do we call it
in the wiki?
Leigh Klotz: I don't know if it's one
or two things yet
Erik Bruchez: One is to convert from
the control to the instance. The gist is a conversion from the
control to the data.
Steven Pemberton: You might use it
with spaces in a credit card number, so it would have no spaces in
the instance and be valid?
Erik Bruchez: That's one of the use
cases. It was a few months ago. One use case is an XBL number
control with formatting options. Currency might include commas and
periods, but in the instnace you would want a canonical decimal.
Unformat goes from the value shown to the data to clean the data.
That's at the data layer but specified on the control.
Steven Pemberton: You could add it in
the model.
Erik Bruchez: We often have things at
both.
Steven Pemberton: Would you start off
an initial page.
Leigh Klotz: I'll start a page that
says there are two things.