See also: IRC log
<trackbot> Date: 05 September 2012
<Steven_> zakim +44 is pfennell
http://www.w3.org/TR/xforms20/ and http://www.w3.org/TR/xforms-xpath/
<scribe> Scribe: John_Boyer
Steven: Congrats and thanks for all the hard work, esp. Nick
Steven: Could have a meeting if enough people
<nvdbleek> http://www.w3.org/2012/10/TPAC/
Steven: It's in Lyon, the culinary capital of France
http://lists.w3.org/Archives/Public/public-xformsusers/2012Sep/0000.html
<alain> http://lists.xml.org/archives/xml-dev/201209/msg00006.html
Timothy wonders if schemas attached to xforms can use includes
Steven: Alain, can you post a followup to ensure Timothy understands that you can indeed have an include
Alain: Yes I can, no action item needed.
http://lists.w3.org/Archives/Public/www-forms-editor/2012Jul/0000.html
<nvdbleek> I responded to this http://lists.w3.org/Archives/Public/www-forms-editor/2012Jul/0001.html
Nick: I sent followup reply, and
Michael said he gets it now but asks for some more examples in
spec or in an accompanying document.
... Better to redirect to XML events spec
Steven: Agrees
http://lists.w3.org/Archives/Public/public-xformsusers/2012Jul/0000.html
Alain: XForms CSS has to be processed with XSLT, which is challenging to performance, so wondering if it is really useful
John: So are you specifically asking about the pseudo-classes and pseudo-elements in appendix G of XForms 1.1?
Alain: Yes, they're hard to maintain
Steven: It's non-normative, so
you'd still be conformant without supporting this, even though
that would interfere with interoperability of
XForms+XHTML.
... I feel your pain having to implement this, and you'll have
to decide whether to support it, but I feel it should stay in
the spec as indicating a way to do it
Nick: The problem is that there is a non-normative section that says how to combine XForms with CSS, but most implementations use their own technique and don't support this
Steven: Many implementations don't do it as pseudo-classes because pseudo-classes don't work, so they are implemented as real css classes
Kurt: Haven't run across a case where they work, and browser makers are unlikely to add enough support any time soon
Steven: I suggest we add to the appendix
<Steven> ACTION: Nick to write up CSS class names as alternative CSS method [recorded in http://www.w3.org/2012/09/05-forms-minutes.html#action01]
<trackbot> Created ACTION-1912 - Write up CSS class names as alternative CSS method [on Nick Van Den Bleeken - due 2012-09-12].
http://lists.w3.org/Archives/Public/public-xformsusers/2012Jul/0002.html
Nick: We talked about doing this as an action and as a function, but we need to pick a way
Alain: I put together an implementation as a function
<nvdbleek> http://www.w3.org/MarkUp/Forms/wiki/Transform
Nick: The problem is that if you
do it with a function, then the dependency system only creates
dependencies on the node(s) used as input to the transform and
the root output node. But if anything changes in the subtree,
no dependencies happen
... Also, the dependencies obtained from the input param is
only on the root node, not all the tree descendants, so if
those descendants change, you won't know to reevaluate the
function
John: Is answer that we need to set dependencies on the whole subtree, perhaps esp. the leaf nodes?
Nick: The structure could change too and you'd want to know to rerun the function, although if there is a structural change you'll get a rebuild so maybe that is not as big of a deal
Alain: Implementations are acting differently anyway with respect to dependencies
Nick: Yes, but we have a spec for how it should be done, and so we should specify how transform() interacts with that. One may be less interested in dependencies on transform if you don't conform to dependencies, but that's not a rationale for ignoring the dependency problem on the transform() function
Steven: Didn't we agree to relax the wording on the dependencies?
Nick: But it wasn't done
John: The definition of dependency was relaxed, both in XForms 2.0 and in a 1.1 erratum, but that was different and a lot less work than relaxing the whole way that recalculation can occur
Nick: I think someone needs to define an upgrade to how dependencies are calculated to cover functions like transform() and id()
Steven: sounds like we need a task force to work on this, and it should include Erik
Nick: Erik and John should be
there
... John knows the current method, and Erik knows his
alternative method really well
Steven: OK, let's put this on hold for a future meeting
John: What was the problem with id()?
Nick: If you change the id of elements anywhere in any instance, the id() function wouldn't know it has to run again
John: OK so the id() function is really a lot harder because it is creating an implicit dependency on everything, whereas the transform() is focused on its parameters
Nick: Yes, and it creates a dependency on all nodes in all instances without even passing them as explicit input parameters nor really implicit default values of actual parameters to the function
Kurt: saying some stuff I can't hear
Nick: You could listen to DOM mutation events on the nodes you're listening to, but that's another way of wording it
John: Except maybe as a note, we probably shouldn't go that deep into how to implement the dependencies
Steven: will come back to it another time
http://lists.w3.org/Archives/Public/public-xformsusers/2012Jul/0003.html
Steven: would be so good if we
could get Michael to join the group
... In this case he wants to show his intermediate stack values
by doing a refresh, but refresh only sets a flag
Nick: yes
John: Actually no, the explicit
action is supposed to actually perform the behavior
... Other actions, like insert/delete/setvalue, set a flag to
get an implicit version of the behavior to happen at the end of
an action sequence
<nvdbleek> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#action-refresh
<nvdbleek> i.e. the behavior occurs without dispatching the xforms-refresh event. This action results in the XForms user interface beingrefreshed, and the presentation of user interface controls being updated to reflect the state of the underlying instance data
John: The only reason to have explicit actions for rebuild, recalculate, revalidate, refresh is to force the behavior to happen immediately, before the end of the action sequence
<scribe> ACTION: Steven to send reply to http://lists.w3.org/Archives/Public/public-xformsusers/2012Jul/0004.html to indicate the xform-refresh action and event should perform the behavior and so it would be an implementation bug if they don't [recorded in http://www.w3.org/2012/09/05-forms-minutes.html#action02]
<trackbot> Created ACTION-1913 - Send reply to http://lists.w3.org/Archives/Public/public-xformsusers/2012Jul/0004.html to indicate the xform-refresh action and event should perform the behavior and so it would be an implementation bug if they don't [on Steven Pemberton - due 2012-09-12].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/functoin/function/ Found Scribe: John_Boyer Inferring ScribeNick: John_Boyer Default Present: +1.323.425.aaaa, nvdbleek, +44.782.483.aabb, Steven_, alain, pfennell, John_Boyer, +1.443.837.aacc, Kurt Present: +1.323.425.aaaa nvdbleek +44.782.483.aabb Steven_ alain pfennell John_Boyer +1.443.837.aacc Kurt Regrets: Erik Agenda: http://lists.w3.org/Archives/Public/public-forms/2012Sep/0000.html Found Date: 05 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/05-forms-minutes.html People with action items: nick steven WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]