Weekly Forms WG Teleconference -- 24 Jun 2009

<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:label>Dispatch Alert Message</xforms:label>

<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

XForms Future Features

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

- DRAFT -

Weekly Forms WG Teleconference

24 Jun 2009

Attendees

Contents

XForms Future Features

Summary of Action Items

Scribe.perl diagnostic output