See also: IRC log
<Steven> woof
<Steven> Hawaii?
<Steven> Ruff!
<John_Boyer> LOL
<John_Boyer> I saw the PR transition request. Thanks for sending that out today!
<Steven> Fine. Hope they notice it.
<Steven> There's usually a transition call first
<John_Boyer> should be able to get the PR transition meeting within a week, then the publication could happen within 1 to 3 business days after that, depending on when the transition call is
<nick> ok
<John_Boyer> Scribe: Leigh
<John_Boyer> scribenick: klotz
<nick> maybe we can break for a week, if we move the virtual day too
<nick> http://www.w3.org/2002/09/wbs/32219/formsabsence2009/results
<nick> for me Jully 9 fits better too
<nick> maybe it is good to have a day further in the summer, then we can prepare some spec ready text
<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_07_02
<scribe> ACTION: John Boyer to move July 2nd vFtF meeting to September 3rd. [recorded in http://www.w3.org/2009/06/24-forms-minutes.html#action01]
<trackbot> Sorry, amibiguous username (more than one match) - John
<trackbot> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)
RESOLUTION: We cancel the July 1st, 2009 teleconference.
RESOLUTION: July 15, 2009 chair Charlie Wiecha, minutes Steven Pemberton.
RESOLUTION: We cancel the July 22nd, 2009 teleconference.
<John_Boyer> http://lists.w3.org/Archives/Public/www-forms/2009Jun/0032.html
http://xformstest.org/2009-06-24.txt
<scribe> ACTION: Nick van den Bleeken to respond to http://lists.w3.org/Archives/Public/www-forms/2009Jun/0032.html by explaining how works. [recorded in http://www.w3.org/2009/06/24-forms-minutes.html#action02]
<trackbot> Created ACTION-557 - Van den Bleeken to respond to http://lists.w3.org/Archives/Public/www-forms/2009Jun/0032.html by explaining how works. [on Nick Van Den Bleeken - due 2009-07-01].
<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2009Jun/0079.html
<nick> <xforms:trigger>
<nick> <xforms:label>Dispatch Alert Message</xforms:label>
<nick> <xforms:alert ev:event="DOMActivate" ref="/msg"></xforms:alert>
<nick> </xforms:trigger>
<nick> http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt08/8.2/8.2.4/8.2.4.a.xhtml
<nick> Ubiquity passes all three, FF pases the 8.2.4.a
<nick> EMC is also passing the three tests
<nick> only Chiba is failing those three
<nick> Chiba will probably pass the three tests if we change the tests
<John_Boyer> ACTION: Charlie to change tests 8.2.4 a,b,c to use an input bound to a number type and ask user to enter "abc" then see alert [recorded in http://www.w3.org/2009/06/24-forms-minutes.html#action03]
<trackbot> Sorry, couldn't find user - Charlie
<John_Boyer> Scribe: Charlie
<John_Boyer> scribenick: wiecha
Nick has responded to Joern that we'll fix these tests
John: recent typos also committed...nick to rebuild zip once new changes are committed
http://www.w3.org/MarkUp/Forms/wiki/Future_Goals
<nick> http://lists.w3.org/Archives/Public/www-forms/2009Jun/0022.html
John: skipping alternative schema until Leigh is available
<nick> <xf:load show="embed" targetid="foo" resource="subforms/foo.xhtml#someId"> is the relevant markup
<ebruchez> I have to leave now, talk to you tomorrow
John: proposal calls for loading
a complete form, including model and UI, and insert dynamically
in for example a <div>
... with the appropriate startup for the model etc
... by extension we could also download simply the UI binding
against the existing model, as for dynamic form controls in a
repeat
Nick: yes, but the init events
are dispatched, so as implemented its more like a separate
subform not interacting with the parent form
... more like an iframe
John: encapsulated makes it easier
<John_Boyer> http://lists.w3.org/Archives/Public/www-forms/2009Jun/0023.html
Charlie: how is initialization handled then>?
Nick: via the server
John: probably has some form of "under the covers" communication between models
Charlie: perhaps just by actions
Nick: main driver was performance problems with large model/schema
John: yes, we deliver only one
page at a time and use server to aggregate content
... and only deliver those pages that are relevant to a given
transaction
... problem is schemas emerging in various industries are quite
large/monolithic
... we need to support interacting with them in subsets...not
clear it requires a new feature for xforms if it's only one
subform
... perhaps so if there are multiple subforms
... why work through the load action?
Charlie: might want to combine this with our shiny-new data-bound switch
Nick: submodel also submits
directly to the parent document model
... so starting again to look like components
John: yup
... sounds like the aggregate applications I've been talking
about, but have assumed a bit more support server-side
... e.g. marshal results of several pages together and let
server decide which pages to deliver to client and when
Nick: yes, that's what Joern is doing. Form lives on the server and we use load actions send certain parts to the client replacing parts of the main page
Charlie: so this is really part of the aggregate application theme
John: use of load does determine
it's client-side processing
... vs option for deferring to server logic
Charlie: would like to consider this together with aggregate theme, e.g. is load right approach?
John: also concerned about load
action in general, not just in this case
... possible overlap with submission
... going forward whatever we do with load we should consider
also for submission
... why not be able to replace tabs, divs, etc with submission
results?
Nick: for me, use load for really
simple case
... without need for submission mechanism in the model...short
hand notation in load
John: yes, authoring convenience
Nick: could extend send with these capabilities
John: yes, but we should be
careful in extending load so it actually remains simple
... vs using submission for some of these features
... rather than fully duplication all features of submission
into load
... so coming back to this proposal if we do something with
load we should also look at supporting similar function in
submission
... Joern is talking about load replacing section of document
with new content, which is full xform
... this provides another driver for model element living in
the body of the document
... think we need this already
... that's the only way to get xforms to run in a portal
environment...multiple portlets with independent models
... not at the head of the page
Nick: yes, but events in the subform don't go to the root
John: but the root is the body
rather than the head
... just pointing out there are other reasons for wanting the
model not to be in the head
... this proposal just provides another similar reason for
doing so
... in the portal case it's server-side code that shares data
across portlets, more recent work allows components client-side
wiring
... rather than xforms submission between components
Charlie: I'm still not convinced
that Joern's case needs this level of separation
... i.e. completely separate subforms
Nick: he uses the subforms as
components
... have their own constraints, model, etc...submit data back
to parent which does the aggregation
John: difficult to componentize if the subform has both model and UI and the invoker has to split this into separate places in the receiving document
Charlie: yes, perhaps the subform can be viewed as a submodel
with controlled access to the parent
vs being completely separate
John: might allow for more
declarative means to connect up the subform and parent
... whether a server round trip is required depends on where
the parent model resides, client or server
... Joern seems to be placing the master model on the
server
... would want to see both model and submodel running on the
logical client
Nick: yes, he has a new type of submission that targets the parent form's model
John: does that then update the parent form's model on the client"
Nick: yes
John: but the server just
reflects whole state of the app
... so the submission from the subform does what type of
replacement?
Nick: submits data to surrounding form subtree, replaces node
John: then in response the master model runs a new load action to load next page?
Nick: yes
John: so the subform submits
directly to the instance data of the master form
... what type of replacement is done?
... none?
... and then the master model runs a subsequent load
action
... for the next subform
Nick: will look for some example markup fragments
John: good to have a working
example but we may wind up satisfying these requirements with
alternative markup
... need to have orchestration across multiple pages, not clear
if it's xforms markup that will need to do this
... first topic for tomorrow
<Steven> bye
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/cancal/cancel/ Found Scribe: Leigh Found ScribeNick: klotz Found Scribe: Charlie Found ScribeNick: wiecha Scribes: Leigh, Charlie ScribeNicks: klotz, wiecha Default Present: John_Boyer, wiecha, Nick_van_den_Bleeken, ebruchez, Leigh_Klotz, Steven Present: John_Boyer wiecha Nick_van_den_Bleeken ebruchez Leigh_Klotz Steven Regrets: Uli Leigh_(partial) Agenda: http://lists.w3.org/Archives/Public/public-forms/2009Jun/0083.html Got date from IRC log name: 24 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/24-forms-minutes.html People with action items: bleeken boyer charlie den john nick van[End of scribe.perl diagnostic output]