Forms WG FtF, TPAC Lyon, Day 3 -- 04 Nov 2010

<Steven> in 15 mins we are going for coffee

<inserted> Scribenick:no-one

<inserted> Scribe: no-one

<Steven> I think so Uli (re your earlier question)

<Steven> The question seems to be down to - Is 'existence' of a control an implementation decision, or do you need to be able to control it

<Steven> and "how do you control presentation in a well-defined way"

<unl> Ok, thanks. I see. I'm just reading the minutes.

<Steven> Eric thinks that there is something fundamental about visibility different from other sorts of presentation, but he hasn't convinced me yet

<Steven> The minutes are rather porr because we were all talking, and forgetting to write down what we said

<Steven> I'm getting more and more enthusiastic about something along the lines of the 'property' mip that I posted to the list

<unl> Yes, I like that too.

<Steven> It is very easy to implement, and hooks into lots of other mechanisms in current implementations

<Steven> @class is very general in XHTML, and is used by lots of sub-processors.

<unl> I am, however, not convinced that all combinations of visible/not and evented/not make sense.

<unl> Especially, I'm concerned regarding John's use case of something being not visible but evented.

<Steven> Well that seems to be the case that they want to catch

<Steven> John mentions wizards where part of the wizard is not visible, but they want to catch invalid events on controls in it

<unl> Yes, but I consider it problematic. I think it is bad or at least insufficient ui design.

<Steven> Well, I agree, but...

<unl> What happens, e.g. when you have a modal message becoming active through some event in a non-selected case?

<Steven> I think John has a use case that collects in a separate subdisplay things that still need to be corrected (even if not visible)

<Steven> Well, good point Uli

<Steven> Welcom Lars

<windauer> Hello everyone

<unl> Hi Lars

<unl> Steven, I see John's point, but I think his use case could be solved by adding a summary page including the option to correct invalid inputs at the of the wizard.

<Steven> Personally, I think the invalidity should show up on the control you are changing, and not on one you have already entered, but maybe that's asking too much

<unl> Yes, I agree completely

<unl> I feel the problem may have its root in that we are saying a non-selected case is the same like a non-relevant group. Maybe that's plain wrong.

<unl> It is inconsistent anyway: You are allowed to style non-relevant groups the way you like, e.g. greyed-out, but a non-selected case should be hidden from presentation at any rate

<unl> Steven, do you know when John, Leigh and Erik might join so we can discuss that further?

<Steven> Not exactly sure.

<Steven> I think round lunch time

<unl> Ok

<unl> I'm eager to solve that puzzle ;)

<Steven> Me too!

<Steven> And I can think lots of ways I can use the 'property' mip, so I've got myself all excited

<unl> Yeah

<unl> Honestly, I don't follow John's critic on property mip vs. generic mip. A generic mip mechanism might be good for implementors, but not for authors.

<windauer> Steven, Nick and me are having lunch. We'll be back at 2

<John_Boyer> neither from tuesday works

<windauer> @Leigh: nope :-)

<klotz> Hi Lars.

<klotz> Hi Uli.

<klotz> Hi John.

<unl> Good morning, Leigh!

<John_Boyer> hi :-)

<unl> Good morning, John!

<Steven> Hi, we're mostly back here

<John_Boyer> Steven, the code is hidden

<nick> hi

<Steven> Not any more John

<John_Boyer> :-)

<John_Boyer> I'm in

<nick> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki

<nick> http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Dialog_Module

<nick> http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Transform_Function_Module

<nick> http://www.w3.org/MarkUp/Forms/wiki/The_XForms_Function_Library_Module

<klotz> status for The_XForms_Dialog_Module says it is the transform function...

<nick> Here is a readme on how to create a new module http://www.w3.org/MarkUp/Forms/wiki/CreateNewSpecModule

<klotz> ditto for library module.

<Steven> 80 missing id's in the spec have to be added

<Steven> The XML Events attributes are foreign attributes and therefore are allowed on any XForms element that includes the Common attributes. This specification lists both Common and Events attributes on XForms actions for reading convenience, i.e. since authors are most likely to place Events attributes on the actual event handler elements.

<Steven> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#Common_Attributes

<John_Boyer> Section 3.2.1?

<Steven> Yes

<raman> Steven, am in the MMIWG now St Claire 2) -- could you pick me up at your next break and I'll come to forms?

<Steven> Sure

<Steven> Curses

<ebruchez> hi Lars

Visibility/Existence/Events or the UI Lifecycle

<nick> scribe: nick

Steven: I send a strawman

<bind ref="sum" property="if(.<0, 'negative', '')"/> ... <output ref="sum"><label>Total: </label></output>

with CSS: output.negative {color: red}

John_Boyer: If we are going to add MIPs we should also look what we have done already related to custom MIPs
... (work done in bind model, with an element based approach)

Steven: custom MIPs is currently not in for XForms 1.2

John_Boyer: We should revisit our triage for XForms 1.2

<John_Boyer> http://www.w3.org//MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html#N65990

ebruchez: I see the benefit of the custom MIPs
... you can do the switch case (with all cases relevant, and only one visible) with the custom MIPs but the visibility wouldn't be in an interopable way

unl: I don't agree because in voice visibility doesn't exists

ebruchez: nobody knows what relevance means in the UI, we are discussing it for 3 FtF meetings, I just want to say that a part of the form isn't there, because it shouldn't be available for the user

Steven: Would something like a model driven switch case do it for you?
... the fact of being accessible should not only be done using css

ebruchez: I want model based switching (it is not about names it is about what it does)
... the group thing is hack to make parts of the form unavailable
... we need a way to control both relevance and visibility of a control
... both with a simple condition
... we want it both in the UI and the model (controlling the relevance and visibility)
... it needs to cover the full matrix (relevance, visibility, events)

John_Boyer: visibility (available for presentation, available for styling) <-> the other thing is availability for eventing system
... currently it is always available for the rendering engine (visibility), because relevance only impacts availability for eventing system (non-relevant controls can be styled)

unl: representing non-relevant controls may be wrong

<klotz> http://xmltoday.org/2010/11/options-for-xml-2-0/

<John_Boyer> non-relevant says UI control is "unavailable" for interaction. Default stying is non-visible, but could be styled as not only not visible but display none, or it could be styled as disabled

John_Boyer: calling 'not being able to the render engine' visibility is wrong
... you have three options

<Steven> Awarable

1) not getting any events (relevant)

2) styled not available (grayed out)

3) fully available

klotz: that's why I called it presentable

ebruchez: how does presentable works?That's how Johns non-relevant works
... John wants to style non-relevant controls

Steven: we need to agree on what we want to solve

<John_Boyer> presentable and eventable => relevant; presentable and not eventable => non-relevant; not presentable and eventable => missing; not presentable and not eventable => missing

klotz: Do we need all 4 posibilities

John_Boyer: Erik wants/needs the presentable and eventable

nick: We need 'not presentable and eventable' for a tab view

unl: the problem might be that non-selected cases are defined as non-relevant, maybe we should change that

ebruchez: we should specify/look what all these 4 cases mean for all controls and if we need them

<windauer> @unl: +1

ebruchez: for layout you should be able to layout the non selected cases to be able to compute the height of a tab view
... the only difference between relevance of a group is that in the tab view we want the events in the non-selected cases
... for performance you want to be able to say that non relevant things aren't available (in big forms you may want to prune non relevant things)
... I'm not yet proposing this, but we may want an extra MIP to control what happens with the 'non available' groups of controls (group, case,..)

John_Boyer: Using groups for model based switch is wrong, only the programmer knows which groups are related
... adding something to switch to handle the non selected cases

Steven: I came up with the terms 'active' and 'present'

John_Boyer: currently in XForms 1.1 you can't control presentability

ebruchez: non-relevant = inactive and present

<John_Boyer> presentable or not presentable; eventable and not eventable

John_Boyer: wait that is not my understanding of active

<John_Boyer> presentable is available to the render engine; it may be styled as visible or not visible but whether visible or not it is *presentable*

<John_Boyer> eventable is whether or not it is hooked up to the eventing system

<John_Boyer> relevant is eventable; non-relevant is non-eventable

ebruchez: we need more then non being eventable (do they update when values change)

<John_Boyer> what does "active" versus "inactive" mean relative to the above?

John_Boyer: what does inactive mean

ebruchez: inactive: a little more then eventable
... then we can say inactive and present
... inactive means doesn't gets events, doesn't updates it internal state

<unl> active = eventable = relevant = enabled

John_Boyer: we should clearly identify the 4 boxes
... what does inactive mean

ebruchez: the opposite of active

<John_Boyer> inactive = presented and not eventable

<Steven> ACTIVE

<ebruchez> active is orthogonal to present

<Steven> Y | N

John_Boyer: relevant= present AND non-eventable
... non-relevant == present AND eventable

<John_Boyer> active == relevant -> presentable and eventable; inactive == non-relevant -> presentable and not eventable

<ebruchez> relevant == active and presentable; non-relevant == inactive and presentable

active = eventable + update state

<Steven> Active Y | N ------------------------ Y | Relevant | Non-relevant Present |----------+------------- N | ? | ?

<Steven> Active

<Steven> | Active | Y | N | ------------------------ | Y | Relevant | Non-relevant |Present |----------+------------- | N | ? | ?

<Steven> | Active

<Steven> | Y | N

<Steven> | ------------------------

<Steven> | Y | Relevant | Non-relevant

<Steven> |Present |----------+-------------

<Steven> | N | ? | ?

ebruchez: it needs to be seen if we want non active controls not to have there values to be updated
... it might be interesting to go back to Use Cases

<raman> coffee break?

ebruchez: What is the expectation when you style non-relevant controls as visible

nick: John what does your implementation do?

John_Boyer: the control is styled grayed out, the values do update, not sure about if validity is updated
... the control is styled grayed out, the values do update, it does show help, hints and alerts, and validity is updated

<John_Boyer> <xforms:model>

<John_Boyer> <xforms:instance>

<John_Boyer> <data xmlns="">

<John_Boyer> <f1>3</f1>

<John_Boyer> <f2></f2>

<John_Boyer> </data>

<John_Boyer> </xforms:instance>

<John_Boyer> <xforms:bind nodeset="f2" constraint=". > 5" relevant="false()" calculate="../f1 + 1"/>

<John_Boyer> </xforms:model>

<John_Boyer> <xforms:input ref="f1">

<John_Boyer> <xforms:label>F1</xforms:label>

<John_Boyer> </xforms:input>

<John_Boyer> <xforms:input ref="f2">

<John_Boyer> <xforms:label>F2 (constraint valid if greater than 5; calculate one more than F1)</xforms:label>

<John_Boyer> <xforms:hint>Hint</xforms:hint>

<John_Boyer> <xforms:alert>Alert</xforms:alert>

<John_Boyer> </xforms:input>

<John_Boyer> In the above, the input bound to f2 is styled as visible, at which point the host language (XFDL) forces the disabled style to ensure the control is "unavailable" for user interaction

<John_Boyer> With f1 having the starting value 3, the calculate on f2 produces a 4 on startup. The input bound to the non-relevant node f2 shows the value 4, since that is what is in the data model

<John_Boyer> The input bound to non-relevant node f2 indicates that the value is not valid since the model constraint is not satisified

<John_Boyer> If the user gestures at the control with the mouse, the user sees an ephemeral "tooltip" window contains Alert in red and Hint in black, reflecting the metadata values for xforms:hint and xforms:alert

<John_Boyer> If the user changes the value of f1 using the first input to 5, then the node f2 is recalculated (despite being non-relevant) and takes the value 6. The UI reflects the state of the model, so the input bound to non-relevant node f2 is updated to show a 6, and its countenance changes to reflect the fact the constraint MIP is now satisfied

<Steven> lol

Load and Embed

windauer: The idea is to load a subform in a running form

windauer: we use the show="embed" and will insert the form at the place of the targetid

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Load_Embedding

nick: is the new form still part of the parent form

windauer: yes it is still part of the parent form
... we also introduced embed="none" to unload the form

<klotz> http://lists.w3.org/Archives/Public/www-forms/2009Jun/0022.html

klotz: I thought joern gave up on it

windauer: he felt misunderstood about his point so dropped

nick: does it has it owns model

windauer: it can only have UI markup and bind to the instances and models in the parent form, but it also could have its own model
... we have model to model communication using submissions to another instance in another model

nick: to be clear the models of the subform become top level

windauer: yes all models are at the same level
... we were thinking of a kind of security to specify what models can submit to what models/instances
... we didn't use XBL2 because we didn't want to introduce another specification, the orbeon work with XBL2 looked also good
... we use it for performance to only load what is necessary, usually we have a master form with a master instance and the master form loads the relevant sub-form when needed (and unloads it when no longer needed)

klotz: you can omit the inter model communication if you have a server, the subform can do a submit, signal the parent form and then the parent form can do a get to get the data from the server
... you could bypass the server part by submitting to a submission in the parent form

<windauer> instanceOfModel('model-1','i-default')/vehicle/carMake

klotz: I think that the model to model communication is a different feature from the load embed feature

Steven: The one makes the other more usefull

windauer: the two are separate things in my opnion

klotz: I like to come on closure on the load proposal and not yet on the model to model communication
... there is a trivial version of the model to model communication using the server (see above) we could even shortcut the need of a server, or even invent a better way...
... I don't like the unload
... I don't like the none
... we need to discuss the life cycle of the model if the new form model, and the uniqueness of the id's

windauer: we dispatch model-construct-done
... xforms-ready is sent

klotz: what is the target

nick: side question, what does it do when the target div is inside a repeat

klotz: what is the event sequence

windauer: it is only xforms-model-construct, xforms-model-construct-done and xforms-ready

klotz: xforms-ready is then dispatched multiple times

nick: maybe xforms-subform-ready

John_Boyer: you use it to set the focus en the selected case

klotz: it could be targeted to the new model

<John_Boyer> setfocus or toggle or setindex

nick: what if you have multiple models

klotz: it could be dispatched to the first model of the sub-form

After all form controls have been initialized and all xforms-model-construct-done events have been processed, an xforms-ready event is dispatched to each model element.

klotz: should we only dispatch the events to the new models

John_Boyer: yes

klotz: unload needs some more thinking

nick: you can do it with a URI that points to an empty element

<xf:load show="embed' target="target" resource="#empty"/>

klotz: what is the resource of the detstory

windauer: we don't need it

klotz: what does it do when it is dispatched to an id where nothing is ever been loaded

nick: what happens when you unload another part of the form (e.g.: a model, instance, part of the UI), what happens when you load in an instance, model,....
... I think we should only load into somewhere in the UI part, and unload should only load what it has loaded

klotz: you should be able to unload itself

John_Boyer: now we can already dispatch model-destruct to eachself
... the interesting part is what happens if the unload itself is followed by setvalue?
... what if an author does an unload followed by a load of the same target

nick: unloading yourself and loading back into yourself is an edge case

John_Boyer: when you unload yourself the actions will stop to run
... so you won't be able to load something again in yourself
... you could use a load action to yourself, that is ok

<John_Boyer> so if you're unloading use unload, but if you're reloading, then just use load and not unload.

<John_Boyer> then we're ok to have models unload themselves

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Load_Embedding

<windauer> http://betterform.wordpress.com/2010/08/16/using-subforms-with-betterform/

<klotz> I added Lar's link above to http://www.w3.org/MarkUp/Forms/wiki/Load_Embedding#Previous_Discussion

<klotz> and we will be looking forward to a fuller proposal from him on www-forms.

http://www.w3.org/MarkUp/Forms/wiki/CreateNewSpecModule

- DRAFT -

Forms WG FtF, TPAC Lyon, Day 3

04 Nov 2010

Attendees

Contents

Visibility/Existence/Events or the UI Lifecycle

Load and Embed

Summary of Action Items

Scribe.perl diagnostic output