Nick van den Bleeken, Inventive Designers
John Boyer, IBM
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (chair, minutes)
Leigh Klotz: I have updated the RNC schema with all reoslutions and put it in the wiki
Leigh Klotz: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0_XSD_Schema
Leigh Klotz: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0_RNC_Schema
Leigh Klotz: John_Boyer we can update the XForms 2.0 wikispec to mention these, but when they are done we still need to populate our MarkUp/Forms/2011 space with the actual files (not in zips) and the TR-space specs and drafts should link there.
John Boyer: It seems better to update the links in the XForms 2.0 spec to point to the wiki versions instead.
Nick van: http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Dialog_Module
Leigh Klotz: It seems like @appearance might not be enough and styling dialogs is outside our scope anyway.
Nick van: If you're reading the spec we have some graphical preview.
Leigh Klotz: The preview is fine but I don't think the appearance hint gives enough info and the pictures might be misleading.
Nick van: I'll get rid of the minimal one
Leigh Klotz: Or just keep only the minimal one. It's not javascript alert.
Leigh Klotz: I think we should remove Additionally a non-cancelable xforms-dialog-close event will be sent to the dialog if a dialog receives an xforms-disabled event, which will close the dialog as its default action.
John Boyer: And if the dialog is modal, don't do that mr form author?
Nick van: That's why I have that text in there. Otherwise modal dialogs become relevant and don't close.
John Boyer: It might be good to keep in mind that we may want to create exceptions for modal dialog bound to non-relevant data. So the author has created what may be regarded as an illegal state and perhap we should notify that by an exception.
Nick van: What is the use of binding on dialog?
Erik Bruchez: We never needed it.
Leigh Klotz: But you have group binding.
Erik Bruchez: Maybe you don't need it.
John Boyer: Group inside dialog.
Erik Bruchez: THat's OK. For us dialog is a toplevel thing. I have yet to be convinced it is not a toplevel thing. We only support them at toplevel. I'm not sure what happens if it becomes non-relevant.
John Boyer: Yes.
Erik Bruchez: We have a dialog in an XBL component. But we don't use that feature.
Leigh Klotz: We do say in here that you can nest dialogs.
John Boyer: As long as you're not applying any UI binding at the top level you never get an in-=scope evaluation context, it's a little bit harder to associate relevance but I see the nested dialog case.
John Boyer: The dialog is not necessarily presented by a group.
Erik Bruchez: The simplest is to remove SNB and MIPs from it.
John Boyer: You don't get relevance from data.
Erik Bruchez: It's like a separate part of the UI, like the main form. The virtual group around the main page you could imagine doesn't disappear. It seems reasonable to say that for reasons of simplicity, it's a toplevel thing. We can let implementors play with it for bindings and nesting but not strictly needed.
Nick van: At the call people wanted to have that. We discussed it briefly.
Leigh Klotz: So let's move it to a note and seek implementation feedback.
John Boyer: Or ask for use cases.
Erik Bruchez: We didn't have that use case.
Nick van: In a repeat you might want a dialog to edit information and now it automatically gets the right context.
Leigh Klotz: It's like subform submission; you dispatch something with data to open the dialog. You can't have all the dialogs in a repeat open at once.
Erik Bruchez: When you see the dialog appear you assume it's not related to a row, but just to provide context.
Erik Bruchez: You could specify a context and model.
Leigh Klotz: I don't see any in-scope evaluation context on a dialog. On the content, yes.
Nick van: If context is empty is the group still relevant?
John Boyer: I think the context node is empty but that doesn't make the group non-relevant. The contained controls are not able to evaluate XPath in that context.
Erik Bruchez: I agree. We already have ref for controlling relevance.
Erik Bruchez: You can have an empty evaluation context in XPath 2.0.
John Boyer: It's dicey from XPath 1.0, but I think that's a mistake. A location step has a nodeset, so it's weird the initial context must have one node.
John Boyer: Typically if we get to the point where you have to evaluate a ref and there is no context node then you get an empty nodeset.
Leigh Klotz: Unless it starts with an instance.
Nick van: Xpath 2.0 with an absolute path will throw an error because you need a context.
John Boyer: OK so it throws its own error. You have to get to ref. What if the first child element is a group and it has a different context, oh how do you evaluate that context?
Nick van: If it starts with instance() or a for-loop it's OK as long as you don't need the current node.
John Boyer: We could say that an XForms processor if initial context node is not there use the root node of default instance.
Nick van: My opinion is not to go that direction. That's opposite of XSLT.
Nick van: YOu can evaluate an XPath expression in an empty context but you cannot use a location path.
Nick van: Couldn't we say it's not allowed to execute in XPath 1.0 in an empty context?
John Boyer: Then it behaves differently in XPath 2.0.
Nick van: or stretch the spec and don't require the context.
Erik Bruchez: It says it's clear.
John Boyer: We use an empty nodeset.
Leigh Klotz: We got into this because I said let's not make xf:dialog a control and have an implicit xf:group inside it as we do for repeat. Then the default context for the group is what we specify, not the dialog.
Erik Bruchez: We can add @context and @model to the dialog. It's always "relevant" because it's toplevel.
John Boyer: Are you trying to sort out what happens when we put a dialog in a repeat?
John Boyer: My preference is to stay simple.
John Boyer: You invoke the dialog and that's an action. At that point you should provide it the context.
Nick van: You can show the dialog with an event and you can provide context in that event.
Erik Bruchez: What do you do then? It's transient. Typically we have an associated model, which we nest inside the dialog. So the dialog has its own local data. Via events the context info can be used to initiazation.
Leigh Klotz: I think dialog is not a form control.
Leigh Klotz: repeat isn't a control either really.
Erik Bruchez: I would say it is.
Erik Bruchez: It usually doesn't have a visual representation.
Leigh Klotz: It doesn't have bindings or do anything with mips.
John Boyer: If you don't express @ref on group it doesn't receive MIPs.
John Boyer: A container form control is used to combine other form controls into user interfaces.
Leigh Klotz: We're not going to allow dialog where we currently allow group, switch, or repeat.
Erik Bruchez: THe only thin it would specify is using the dialog as a toplevel entity.
John Boyer: We can say it's a toplevel entity and by not adding it to the content model.
Leigh Klotz: Right, it doesn't go on the group form controls list.
Erik Bruchez: It bothers me to say it's not a control.
John Boyer: We can have nestable form controls and non-nestable.
Leigh Klotz: Is there a formal definition of container form control with events?
John Boyer: If it's a container form control it can then be in another dialog.
John Boyer: It seems like a lot of trouble to avoid putting control inside repeat. What are we trying to avoid?
Erik Bruchez: When you put a dialog in a repeat you have a lot of questions. Are there ten dialogs or one open ten times or can it prevented only once?
John Boyer: don't you have those problems anyway? You can invoke the action 20 times.
Erik Bruchez: In our case we can only open it once.
John Boyer: Then you have rules.
Erik Bruchez: Then the issue was relevance. That was the complexity.
John Boyer: We set if it's modeless you hide it and if it's modal you close it.
Erik Bruchez: YOu can just close it.
Nick van: You can have multiple ones.
Erik Bruchez: It's a question of which option is the simplest; it's a tradeoff between use cases and complexity. If it's simpler to cover use cases nobody needs, then we should do that.
Leigh Klotz: xforms.Container.Form.Controls =
Leigh Klotz: xforms.group | xforms.repeat | xforms.switch
Leigh Klotz: xforms.repeat.content =
Leigh Klotz: (xforms.Core.Form.Controls
Leigh Klotz: | xforms.Container.Form.Controls
Leigh Klotz: | xforms.UI.Inline.content)*
John Boyer: SO it is a thing that is not a "container form control" that contains not controls.
John Boyer: s/contains not controls/contains form controls
John Boyer: this prevents it from being nestable, i.e. imposes the top-level restriction. whereas a container form control is something that, by being a form control, is nestable
John Boyer: It's the only one that doesn't have binding, isn't nestable, can't contain itself, etc.
Erik Bruchez: As a human, it's very easy to say what it is. It's a toplevel container control.
Erik Bruchez: if we had a proper language.
Erik Bruchez: the difference between the two is that switch is containable but dialog doesn't have that property.
Leigh Klotz: xforms.Container.Form.Controls = toplevel.containers | nestable.containers
John Boyer: dialog is a container, which is different from being a container form control. The fact that it is a container doesn't mean it is a form control
John Boyer: There's two concepts: container and form control. repeat and switch are both. dialog isn't a form control.
Erik Bruchez: Yes it is.
John Boyer: Well, it's not nestable and has no bindings.
Erik Bruchez: My counterargument is that every framework language calls it a widget or control. It's a UI thing on the screen.
Leigh Klotz: Switch never shows up on the screen.
Leigh Klotz: If I ask for the following-sibling in the document?
Leigh Klotz: It's more like a script element.
Erik Bruchez: You could say dialog+p
Erik Bruchez: What are the options: we could say it is not a control and not a container control.
Leigh Klotz: As long as we never defined "container form control" with semantics it's ok.
Leigh Klotz: But we'll have to put in two exceptions.
Erik Bruchez: How is this different from a toplevel group without a binding?
Erik Bruchez: my concern is that it will be really weird to look at the spec and see it's not quite a container control.
Leigh Klotz: But MIPs don't apply to it.
John Boyer: We're only saying it to get around processor problems.
Leigh Klotz: OK maybe we'll learn something and it's not fundamental. So let's take the ref off and say it's toplevel only and then put in a note requesting implementors.
Leigh Klotz: OK, let's put the word toplevel before "container form control" and remove the language about relevance and ref.
Nick van: OK
Leigh Klotz: Let's make dialog have an implied group like repeat does. Then we can change the "behave as if in a group" to be more concrete.
Leigh Klotz: "The implied group in a closed dialog is not relevant."
John Boyer: The repeat implied group relevance is implied without ref="." as a hack, because we need to group to inherit the context node and context position.
Leigh Klotz: I would say it gets the context from the first instance or from @context and @model.
John Boyer: I thought the invoking dialog would specify context info.
Nick van: It would be cool but it sounds.
Leigh Klotz: Why don't you send that in as a comment.
John Boyer: s/invoking dialog/invoking action for the dialog
Leigh Klotz: I thought we'd do this by sending the copy of the data back and forth.
John Boyer: because I'm commenting now :-)
John Boyer: no need to copy the data, just send the context
John Boyer: We discussed sending the context info including repeat before when we discussed dialog.
John Boyer: In the past we had talked about putting dialog directly in repeat.
John Boyer: so we didn't need to send the context node
Leigh Klotz: It's been a long time since XForms 1.1 came out and we still don't have dialog and I think it's because of events. Making it toplevel seems like a small price to pay to get implementations.
Nick van: There are three implementations.
Leigh Klotz: How do they handle being nested in repeat?
Erik Bruchez: It would be nice to do master/detail but it becomes harder to implement. In reality we create a single dialog outside.
John Boyer: We have something similar; we implement dialog as well and we use a function or action from and the dialog content itself pulls and pushes data. It's a subform and it pushes data back.
Leigh Klotz: If you lose the chose the voice.
Leigh Klotz: s/chose the voice/choice to cancel
Nick van: If you bind to the context directly, you do the edits directly live in the instance. This solution forces you to copy the instance and on document close you copy it back, on OK.
Erik Bruchez: Which is often what you want anyway.
Leigh Klotz: ...
Erik Bruchez: That's what we do anyway.
John Boyer: The context is where you send the data back in an OK, not the group context. It's not a context.
Erik Bruchez: It's like targetref.
John Boyer: That's what we should pass to the dialog.
Nick van: It's the wrong way around because the dialog has to know where to put the data. It's cleaner to send the updated data back and the caller can handle it as a returned value.
Erik Bruchez: You want a closure as in Xpath 3, a first-class function to send back.
John Boyer: You want the initial data too.
Erik Bruchez: On xforms-dialog-open you pass in context info. When you close it you listen for the event and get the data.
John Boyer: So the repeat case already works then.
Erik Bruchez: It's super easy to pass information to the dialog if you copy the data to your own instance or model. For the return it's harder for the repeat because if you want to store it back how does the dialog remember that location?
Leigh Klotz: That's the unsolved problem from Monday: how do you get the data back from subforms.
Erik Bruchez: If the dialog only writes it in one place you can put the listener in the repeat. Hopefully it will reach the right iteration.
Nick van: No, but you can pass in extra information saying who called you.
Erik Bruchez: We use saxon path and evaluate. It's a hack. We pass you the "place" to write the result and the dialog gets a unique path to write back.
Leigh Klotz: I agree we need a better solution but I'm not sure we're coming up with a design today.
John Boyer: I don't understand what you mean by xforms-dialog-open you pass context info. Why doesn't the dialog remember context-info and send it back to dialog-close?
Erik Bruchez: How do you store a pointer to a node?
John Boyer: You can store it. We store the identity in repeat and switch. Why not dialog?
Leigh Klotz: The machine code.
John Boyer: And then give it back to the close event.
Erik Bruchez: You might need 3 such parameters, not exactly 1. It would be generic to use events and I'm happy with events to pass informatiopn in.
Leigh Klotz: You can't store a reference to an element, except an ID.
Nick van: On the close event you can have a condition on actions to send to the correct iteration. You can provide the index in the extra super parameter. Then the close event you send it back. All the events will get handled but you get the correct run.
Erik Bruchez: You dispatch to the repeat iteration.
Nick van: There will be the same id multiple times.
Erik Bruchez: In a modal dialog the index won't have changed. That is brittle. It's hard.
John Boyer: Internally you have instance data that allows you to store the index and consume that to close the dialog to copy back.
Erik Bruchez: There are possibilities; I'm happy not to put a dialog within a repeat. There are ways.
Leigh Klotz: It would be best if the caller got the data back out.
Nick van: We could provide an id of an action to run on completion.
Erik Bruchez: We have an effective-id which includes iterations. None of these are very beautiful.
Nick van: It's cleaner to run the iteration and know the uniquified id.
Nick van: if we had run-id-foo on completion.
Erik Bruchez: Which context if it is in repeat?
Nick van: We already have ID resolution in repeat; it's the id=foo that's currently effective.
Leigh Klotz: As long as the repeat iteration doesn't change.
Nick van: If someone sends an event in the repeat, it doesn't have to be the current one.
Erik Bruchez: The dialog is outside the iteration.
Nick van: Replace it with the effective ID.
Erik Bruchez: But we don't have that. We can pass target and repeat index. THen you do setindex and dispatch. But it's horrible.
Nick van: The show-dialog action could take an additional argument that says to run the ID on completion.
Erik Bruchez: The XForms engine could know which iteration to dispatch to. But what is completion?
Leigh Klotz: That's almost exactly what John's asking for; it should just know the context from where it was invoked.
John Boyer: The send action dispatches xforms-submit to submission. I would assume dialog would dispatch dialog-open. The event context should contain the context of the invoking dialog action.
Erik Bruchez: http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Dialog_Module
Erik Bruchez: The show elemnent.
John Boyer: I assume that dispatches an event and could put in the in-scope evaluation context of that show element.
John Boyer: Then you can do anything you want with it including setvalue.
John Boyer: That's easy but how do you communicate back.
Nick van: You can't put in a node in the context; it's a clone.
Leigh Klotz: So
John Boyer: s/John: That's easy but/Nick: That's easy but
Erik Bruchez: If we had context. So dialog upon receiving the show event has the context.
Nick van: You could put context node, position, etc and at close event...
Nick van: It just needs the context item.
Leigh Klotz: s/Nick/Erik
John Boyer: the xforms processor for dialog can be equipped with the ability to store the context info node received by the dialog open event so that it can include that same node in the dialog close event
Erik Bruchez: By magic it stores a reference to that context node, and there's a function.
Leigh Klotz: Like current()
John Boyer: then you can refer to it in dialog open and dialog close action handlers using the event() function
Erik Bruchez: current() is already specified.
Leigh Klotz: The reference should be available to an xpath expression, either a custom function or an event() result.
John Boyer: ...
Erik Bruchez: That's what we do using eval(). But you have to know the instance.
Erik Bruchez: it's a workaround. In a way I would kind of prefer that because it doesn't require dialog magic or magic in close.
Nick van: ...
Erik Bruchez: There would be no magic .
Leigh Klotz: You don't need anythig other than the ability to set context.
Erik Bruchez: The dialog doesn't need to magically store the canonical path. But you need another attribute on show and a new function.
Leigh Klotz: Can't you retrieve the info at any time?
Nick van: no, only when processing the event.
Erik Bruchez: You could do it with a global canonical path function and evaluate.
Nick van: It won't work if the context isn't in an instance.
Erik Bruchez: All thsi remains a workaround for something better.
Erik Bruchez: It almost makes you want to put the dialog in the repeat.
Leigh Klotz: That makes you implement the magic.
Erik Bruchez: You're not repeating the dialog. It's just the context.
Leigh Klotz: That's why John wanted the show-dialog to pass the context to the dialog.
Nick van: You could have multiple versions of hte same dialog.
Leigh Klotz: So John's idea is to put the dialog at toplevel and say that the group in-scope evaluation context is set from the invocation of the show-dialog.
Nick van: What if you have two invocations simultaneously?
Erik Bruchez: Don't do that.
Erik Bruchez: Most of the dialog wants its own context.
John Boyer: You'd get the value from the event, not the group in-scope evaluation context.
Leigh Klotz: During the processing of the event it works but the UI interaction happens after handling.
John Boyer: The xforms processor could keep track of the object.
Erik Bruchez: Only the show action and the close event would have this information so we don't need the function to obtain it.
Nick van: The user can use the close action or send the close event, but if it sends its own close event how does it get it?
Leigh Klotz: So I dispatch a close event with no context info but when the dialog receives it it has the correct context info?
Erik Bruchez: Exactly. The origin-context is stored by the dialog.
Nick van: What if you dispatch the close yourself?
Erik Bruchez: It's added by the show action and then dialog itself adds it to the close event. You get it back on the close event yourself.
Nick van: You can't send events yourself. You'd have to use show and hide.
Erik Bruchez: Right. You must use the actions.
Nick van: but not on close
Erik Bruchez: Not on close
Nick van: Then you can't add extra information on close.
Erik Bruchez: We discussed async submission with custom data with custom data passing back.
Erik Bruchez: It's up to the caller to know what to do with it. The caller that opens the dialog conceptually wants to know something back. We don't have a perfect solution but we do have hte context information. The solutions aren't perfect but
Erik Bruchez: when the dialog closes if you need to relate the two pass the context. XPath and evaluate, element ID, iteration index, etc. It puts the burdern on the form author, but it also doesn't require any magic to be added to XFOrms.
Leigh Klotz: So it has to be serializable.
Leigh Klotz: Do components solve this? They solve the multiple instantiation of dialogs problem and maybe they solve the return value problems?
Erik Bruchez: The component can dispatch an event to its outside self.
Leigh Klotz: I think that'st he case. We have several solutions to passing data back and forth.
John Boyer: I Agree. If someone invokes dialog when already running that produces an error?
Leigh Klotz: Let's do the same as with submission.
John Boyer: I think that works. I have machinery to tailor dialog to work in repeat. In an idea world you would need context but you probably know enough.
Leigh Klotz: s/idea /ideal /
Leigh Klotz: I think it's good enough for first draft, and multiple instantiations and returned value locations are component problems.
John Boyer: I agree.
John Boyer: Is it going to be a module?
John Boyer: If it's ok I'd like to keep it separate for now.
Nick van: It's on the main page under XForms 2.0 spec, along with XPath Expression module.
John Boyer: Let's put it on the one page.
John Boyer: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0_edit
Resolution 2011-08-31.1: dialog is a toplevel container form control. It contains an implicit group. Dialog does not have SNB and consequently does not receive MIP bindings.
Erik Bruchez: I did a first pass at the valid() function: http://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module#The_valid.28.29_Function
John Boyer: It's a lot of work. I hope it's useful.