See also: IRC log
<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
<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
<windauer> <xf:load show="embed" targetid="xforms">
<windauer> <xf:resource value="'GroupVerticalTableComplex.xhtml#xforms'"/>
<windauer> </xf:load>
windauer: The idea is to load a subform in a running form
<windauer> <div id="xforms">
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
<insert nodeset="instance('super-model', 'instance-id')" origin="instance('subform-instance')"/>
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
<div id="empty"/>
<windauer> <xf:load show="embed" targetid="idWhereToLoad" />
<windauer> <xf:load show="destroy" targetid="idWhereToLoad" />
<xf:load show="embed' target="target" resource="#empty"/>
<Steven> <xf:unload targetid="wherever"/>
klotz: what is the resource of the detstory
windauer: we don't need it
<klotz> <h1 id="foo">Hi</h1> ... <unload target="foo" />
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.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Steve/Steven/ Succeeded: i/I think so Uli/Scribe: no-one Succeeded: i/Scribe:/Scribenick:no-one Succeeded: s/hidden/visibility/ Succeeded: s/with should make it possible to make non selected cases 'available'/the problem might be that non-selected cases are defined as non-relevant, maybe we should change that/ Succeeded: s/active = eventable = relevant/active = eventable = relevant = enabled/ Succeeded: s/do/do?/ Succeeded: s/<f1>/<f1>3/ Succeeded: s/droipped/dropped/ Succeeded: s/miss understood/misunderstood/ Found ScribeNick: no-one Found Scribe: no-one Found Scribe: nick Inferring ScribeNick: nick WARNING: No scribe lines found matching previous ScribeNick pattern: <no\-one> ... Scribes: no-one, nick ScribeNicks: no-one, nick Present: Steven Uli Nick LarsWindauer John Leigh Raman Erik Agenda: http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12 Got date from IRC log name: 04 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/04-forms-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]