Forms Working Group Teleconference -- 10 Feb 2010

<trackbot> Date: 10 February 2010

<Steven> You on for scribing Charlie?

yup, planning on it

<Steven> Thanks

np!

note that the conf code is actually 26633, not 26631 as in agenda

<Steven> Yep, see Topic

yes, correct there

<Steven> @Zakim bridge, for code check the IRC channel, likely to be CONF1 (26631) irc channel irc.w3.org #forms@

<Steven> So only 'likely to be'

<Steven> What's Leigh doing in the IRC channel???

<klotz> on my phone

<Steven> Scribe: Charlie

<Steven> scribenick: Wiecha

Rechartering

Steven: have received review, editorial changes only which I have made

<Steven> http://www.w3.org/MarkUp/Forms/2009/charter2010.html

Steven: timeline updated with more detail
... necessary to continue VBWG as liaison? thought so, yes

I agree

Steven: otherwise, positive review so mgmt team discussing this afternoon (now)
... anticipate hearing tomorrow

<klotz> http://www.w3.org/MarkUp/Forms/2009/charter2010.html

Steven: anticipating favorable review, don't see reasons for objections
... so we should plan for seeing a call to go out next week, probably Monday
... gives us just a month before F2F
... so we can go ahead with that date

Nick: yes

Steven: I will work out locations

I am holding space at IBM in Cambridge as well

<nick> though still have to ask for permission to travel

<nick> the sooner we know it goes forward the better

Steven: we should start contacting potential new members of the WG, e.g. those active already in using XForms

Charlie: let's plan on using the conf room space at IBM...large room, external windows, etc

<nick> Charlie is it on 1 Rogers Street, Cambridge?

Steven: agreed

yes, Rogers st

Steven: potential folks to contact: formfaces
... ampleSDK
... yahoo for mobile
... now joining more WGs, e.g. RDFa
... could ask Micah

<klotz> can we consider Alain for Invited Expert?

for a name

EMC

<klotz> I will ask Microsoft and MarkLogic.

<Steven> Good idea about Alain, Leigh

<Steven> Kurt Cagle

<klotz> and Dan McCreary

<Steven> Kurt Cagle

<Steven> Yes Leigh

<Steven> Any other invited expert?

News items

Steven: have updated home page with a bunch of news items

<klotz> What about Mark Birbeck's status? member or expert?

<Steven> expert

Tests that need work

http://lists.w3.org/Archives/Public/public-forms/2010Feb/0009.html

<Steven> http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt10/10.8/10.8.e.xhtml

has some incorrect markup for event handlers and is missing an instance which is required

Steven: instance shouldn't actually be required due to lazy authoring
... all ok with proposed changes?

<Steven> http://www.w3.org/MarkUp/Forms/Test/XForms1.1/Edition1/Chapt10/10.8/10.8.f.xhtml

I can take both of these

<scribe> ACTION: wiecha to fix tests 10.8.e and f as per discussion in emails [recorded in http://www.w3.org/2010/02/10-forms-minutes.html#action01]

<trackbot> Created ACTION-605 - Fix tests 10.8.e and f as per discussion in emails [on Charles Wiecha - due 2010-02-17].

Load/Unload events in XForms

<Steven> http://lists.w3.org/Archives/Public/public-forms/2010Feb/0007.html

http://lists.w3.org/Archives/Public/public-forms/2010Feb/0007.html

Erik: given evolution of events in DOM, e.g. focusin and out and activate being deprecated

perhaps load and unload would make sense for us to use them?

HTML authors are used to load

in XForms we tend to use model-construct-done and ready

using load would benefit from familiarity and would be short

Erik: John commented on the list that this could be used to better describe our lifecycle with the containing document
... load could be trigger to init our own stuff

Steven: you get load in two or three cases...document as a whole, then images
... detailed questions on page lifecycle...when is everything ready? just done with parsing?
... is this as useful as xforms-ready?
... need all constraints etc to be updated

Erik: it's pretty late

Nick: in HTML load is sent after js has been run

Steven: but not all images are in place

Charlie: forms authors would still need to wait for our events to begin

Erik: load might be used instead of xforms-ready

Steven: xforms would normally start initting the engine after load occurs

Erik: implementors might have some freedom to start initializing earlier than load
... if we want to use load, we would say xforms impls would redispatch the same named load event on the model to signal xforms readiness
... any timing issues in terms of engine startup could be managed in between the document load and redispatched load

Nick: this would probably replace model-construct-done

Erik: no, that's earlier than ready
... UI tree is initted before ready

Nick: normally, "load" implies everything is ready so would come not before the model is ready

Erik: right, should come after

Charlie: could be confusing if you listen for the wrong "load" event

Erik: would perhaps depend on an impl
... xforms-model-construct-done is useful since lots of function is ready then, even if controls aren't present
... but needs a better (shorter) name

<klotz> perhaps load belongs to html...js vs "native" as xforms ua might encounter it at different times or not at all

Erik: "load" would be closer to xforms-ready not model-construct-done
... we use model-construct-done in almost every form

Nick: us too

Erik: since we can do lots of work without triggering updates to controls which aren't needed until after all the init is done
... we have an action that runs synchronously to block until a set of async submissions complete, so we can block the UI construction until we're ready to go ahead
... not clear that load/unload is easily included
... perhaps we should tee up another topic on model-construct-done

Charlie: perhaps we can look more closely at the startup lifecycle and see if we could support this action pattern more as a first-class part of xforms

Erik: ok, I'll write up an email on this and we can discuss later

<scribe> ACTION: Erik to write up example and discussion of model startup with async submissions before UI construction [recorded in http://www.w3.org/2010/02/10-forms-minutes.html#action02]

<trackbot> Created ACTION-606 - Write up example and discussion of model startup with async submissions before UI construction [on Erik Bruchez - due 2010-02-17].

Submit and Trigger availability during (multiple) submissions

http://lists.w3.org/Archives/Public/public-forms/2010Jan/0022.html

Steven: original design of submit/trigger was intended to avoid duplicate submissions
... doesn't fit well into async world, and we could reconsider
... seems to be something that should be declarative

submit is declarative...knows what it's submitting, where to, etc

trigger on the other hand doesn't have that direct knowledge of what's being triggered

<klotz> people like to style triggers differently depending on state. so css or something should be able to find out

ideal would be declarative way to say a button should be disabled until something happens

submit would be the simpler case, but trigger could drop down and do multiple submissions, e.g. by data-driven construction of a URL

which would be in principle valid at any time

<klotz> not just disabled, but different, either via css or switch. "search" button changes to swirly gif thing.

could use SNB on trigger to control availability

so the author can control whether the button becomes disabled or not

<ebruchez> that's the Cylon mode

Charlie: let's discuss again at the F2F whether Submit vs. Trigger could capture the simple vs. more general multiple-submission case

JSON initialization of instance data

<klotz> did you see the example I sent from xsltforms json?

<nick> http://www.agencexml.com/jsoncallback/wikipediasearch.xml

<klotz> as near as I can tell, the xforms document author does not have to write a callback method as in some previous proposals we have discussed.

Steven: reports that the team has approved the charter for distribution

<Steven> Woohoo!

<klotz> charter is findable by search engines "xforms charter 2010"

<Steven> News just came in

<Steven> Yes Leigh, that is the result of a public WG ;-)

Charlie: reports on progress implementing JSON import/export
... raises question of whether a single simple parsing policy would be sufficient since if we're targeting external JSON data this will never have mixed content nor attribute values

so perhaps we don't need the full set of "fish" parsing options discussed earlier

<Steven> What happened to Zakim?

<klotz> sounds like we need a clear statement of use cases.

will post examples/discussion to the list but there's a simple version of src attributes using script JSON content working now in Ubiquity

yup, agree on need to nail down specific use cases

<Steven> Finished CHarlie?

yes, thx

- DRAFT -

Forms Working Group Teleconference

10 Feb 2010

Attendees

Contents