See also: IRC log
<ebruchez> zakim [IP is ebruchez
<John_Boyer> zakim sure is busy
<Steven> trackbot, start call
<Steven> trackbot-ng, start call
yes john
one earlier then now
meeting time is stable to GMT
<Steven> no, stable to Boston
ok
depends when GMT changes
<Steven> GMT never changes
<John_Boyer> Scribe: Nick
<John_Boyer> scribenick: nic1
<Steven> scribenick: nic1
<Steven> trackbot-ng,help
Steven: The html calls moves 1 hour, so there is a collision of 15 minutes
<Steven> trackbot-ng, help
<trackbot-ng> See http://www.w3.org/2005/06/tracker/ for help (use the IRC bot link)
<unl> sorry for being late, had to go to the pharmacy, my daughter is not feeling very well
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Mar/0011.html
John: Ok then steven and mark will be 15 minutes late
http://lists.w3.org/Archives/Public/public-forms/2008Mar/0004.html
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Mar/0004.html
John: We need to say which days
we want to meet
... They wanting to change the schedule, and allow meetings to
overlap, to avoid the meeting day at Saturday
... Mo-Tu or Th-Fri or only one day
... No more Saturdays
Steven: I think we only don't want a clash with XHTML
<John_Boyer> Oct21-22 versus Oct.23-24
John: Does anyone, have a preference for earlier or later in the week for XForms?
silence
John: We will go for no preference in days
<John_Boyer> But "two days needed"
John: We got a response from Martin Duerst, steven can you have a look to the response?
Steven: Surely
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Feb/0074.html
<scribe> ACTION: Steven will propose wording for appendix E in response to http://lists.w3.org/Archives/Public/public-forms/2008Feb/0074.html [recorded in http://www.w3.org/2008/03/05-forms-minutes.html#action01]
<trackbot-ng> Created ACTION-454 - Will propose wording for appendix E in response to http://lists.w3.org/Archives/Public/public-forms/2008Feb/0074.html [on Steven Pemberton - due 2008-03-12].
John: Got some push back from HCG
to use the wiki for requirements
... They want it to be published as a WG Note
... We can go on writing it on the wiki, and in a couple of
months we can convert it to SpecXML
<Steven> "Purpose: A Working Group's Last Call announcement is a signal that:
<Steven> the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft;"
<Steven> The process doesn't require a requirements doc, but doesn't forbid one either
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Mar/0010.html
John: We wanted to figure out what the simplified syntax is for a purchase order
http://www.w3.org/MarkUp/Forms/wiki/Add_model_item_properties_to_UI_level
<John_Boyer> Need to decide whether MIP attributes on controls create MIPs or whether they create properties of UI controls
<John_Boyer> If the former, then we need "Unified Context" work from nick
<Steven> I vote for MIPs
<John_Boyer> If the latter then we don't need "Unified Context" but it's a lot more work to describe the processing model for UI properties
<Steven> ... makes the processing model more obvious, and creates fewer new rules
ack, me
<John_Boyer> Nick agrees with Steven
<unl> +1 for MIPs
<John_Boyer> Erik: Not sure it matters much to the author
Nick: I agree implying MIPS (binds)
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Unified_evaluation_context
Erik: I think that making the simplified syntax well is more important then mapping it to existing structures, it should stop us if we need to create a lot of new spec text
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
Erik: We talked last week of combining MIPS, and that is NOT related to simplifying forms
<ebruchez> uh, that is NOT related
John: There is the mandatory section and Supplementary and the example is in the Supplementary
MarkB: I've done some work on it
John: We talked a lot of implying mips on the binds, but mark asked last week if we already decided if they aren't local to the UI
Erik: We could define the evaluation context of the readonly attribute on the UI elements
<John_Boyer> Erik: The evaluation context of these new attributes could be different than how we currently define it
<John_Boyer> MarkB: Favors locally attaching the properties to the UI controls
<ebruchez> <xforms:output ... calculate="a + b">
<John_Boyer> <xforms:output name="c" calculate="power(a*a+b*b, 0.5)"/>
John: A good example is
evaluation context for the calculate of an output
... Explains the name allows references to the result of the
output control
<John_Boyer> Nick: Doesn't the "variable" concept (the dollar proposal) break down inside a repeat?
<John_Boyer> John: Yes I suspected it would
<John_Boyer> John: That's why I want to do this example.
<Charlie> how would this work in HTML4/5 forms?
John: I want it to create elements, the UI imposes the structure of the instance
<John_Boyer> <repeat name="order" nodeset="row">
<John_Boyer> <input name="Product">...
<John_Boyer> <input name="Quantity">
<John_Boyer> <input name="Price">
<John_Boyer> <output name="LineTotal" calculate="Price* Quantity"/>
<John_Boyer> </repeat>
Erik: proposes a control() which will refer to the elements produced by the ui control
<ebruchez> sum(control('line-subtotal'))
<John_Boyer> <output name="subtotal" calculate="sum(order/row/LineTotal)"/>
MarkB: explains that referring to the value of elements (binds, ui controls) with xpath-variables
Erik: We have to be careful with how we use variables
MarkB: A variable is a
nodeset
... Explains that all binds could be available in the UI
John: Explains the example he just posted
Erik: I want to see full examples of possible simplified syntax, then we can choose the best one
<John_Boyer> I think the above markup for PO implies this data:
<John_Boyer> <data>
<John_Boyer> <order>
<John_Boyer> <row>
<John_Boyer> <Product>
<John_Boyer> <Quantity>
<John_Boyer> <Price>
<John_Boyer> <LineTotal>
<John_Boyer> </row>
<John_Boyer> </order>
<John_Boyer> <subtotal>
<John_Boyer> </data>
<John_Boyer> And these binds:
MarkB: Your proposal omits '..' this will need a change in our spec, and your proposal doesn't uses a calculate and not a value
<John_Boyer> <bind nodeset="order/row"> <bind nodeset="LineTotal"><calculate context=".." value="Price*Quantity"/></bind></bind>
<John_Boyer> <bind nodeset="subtotal"> <calculate context=".." value="sum(order/row/LineTotal)"/></bind>
MarkB: The architecture is important, I would propose that a control creates a bind and you will then be able to refer to that bind
Nick: Your name is just a ref that doesn't changes the inline evaluation context of the other attributes on the control
<markbirbeck> <label for="unitCost">Unit Cost</label>
<markbirbeck> <input id="unitCost" name="unitCost" />
<markbirbeck> <xf:bind id="auto_1" nodeset="unitCost" />
<markbirbeck> <xf:input bind="auto_1">
<markbirbeck> <xf:label>Unit Cost</xf:label>
<markbirbeck> </xf:input>
MarkB: Explains his proposal
<markbirbeck> <input name="unitCost" />
<markbirbeck> <xf:bind id="unitCost" nodeset="unitCost" readonly="true()" />
<markbirbeck> <xf:bind nodeset="unitCost" readonly="true()" />
<markbirbeck> So what I'm getting at is that this should be able to work, in whatever model we adopt:
<markbirbeck> <xf:bind nodeset="unitCost" readonly="true()" />
<markbirbeck> <input name="unitCost" />
I think so, otherwise it would be a failure of us
<markbirbeck> that way the author is very gradually adding more and more XForms.
John: Ok so, I'm not seeing a lot of difference between Mark's and mine proposal
MarkB: You are saying that your name is a ref and in my proposal it is a bind
<markbirbeck> <xf:output id="lineTotal" value="$unitCost + $qty">
<markbirbeck> <xf:label>Line Total</xf:label>
<markbirbeck> </xf:output>
MarkB: John is referring to a node, in mine you refer to a variable
<Charlie> mark, could you please give the subtotal expression in IRC?
<Charlie> .e. sum over lineTotal...
Erik: We also need local variables, not only the 'global' bind variables
http://www.exforms.org/variable.html
Erik: we need to make it consistent, definitely the scoping rules
<markbirbeck> <xf:output name="lineTotal" value="$unitCost[7] + $qty[7]">
<markbirbeck> <xf:label>Line Total</xf:label>
<markbirbeck> </xf:output>
MarkB: Wonders if the syntax will work in a repeat
<markbirbeck> sum($unitCost)
$unitCost[index()]
<markbirbeck> yes nic1 :)
<markbirbeck> 7 was easier to type :)
John: We need some further work
on it
... Even before the next week...
bye
<Roger> bye
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/So the next calls will start 15 minutes later, it is still 15 minutes longer then before/Ok then steven and mark will be 15 minutes late/ Succeeded: s/no new/fewer new/ Succeeded: s/is related/is NOT related/ Succeeded: s/my-control/line-subtotal/ Succeeded: s/lael/label/ Succeeded: s/lael/label/G Found Scribe: Nick Found ScribeNick: nic1 Found ScribeNick: nic1 Default Present: +1.919.254.aaaa, wellsk, [IPcaller], ebruchez, Nick_van_den_Bleeken, John_Boyer, +34.91.211.aabb, Roger, markbirbeck, Steven, unl, Charlie Present: +1.919.254.aaaa wellsk [IPcaller] ebruchez Nick_van_den_Bleeken John_Boyer +34.91.211.aabb Roger markbirbeck Steven unl Charlie Regrets: Leigh Susan Joern Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Mar/0011.html Got date from IRC log name: 05 Mar 2008 Guessing minutes URL: http://www.w3.org/2008/03/05-forms-minutes.html People with action items: steven WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]