- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Mon, 27 Apr 2009 09:59:54 +0100
- To: Charles F Wiecha <wiecha@us.ibm.com>
- Cc: Jack Jansen <Jack.Jansen@cwi.nl>, public-xg-app-backplane <public-xg-app-backplane@w3.org>
Hi Charlie/Jack, I think what you describe (sequences, communicating with XForms, etc.) is already doable, but as you say, it's thinking of a use-case to test this that's tricky. My two-penneth on the general problem would be this; the key communication mechanism is already DOM 2 Events, and should remain so. IMHO, XForms relevance doesn't have anything special to offer SMIL functionality, any more than the document load event, a key press event, a file updated event, a geo-location changed event...or as I discovered the other day on my Apple Mac, the 'computer tilt event'! :) Relevance changing is just one event amongst many. So for my money, the tricky thing to model is emulating a 'timing grid' that has at its core DOM 2 Events. My understanding of SMIL is that the _initiation_ of a timing sequence is left open, so that you could say that anything could start a timing sequence. But at the moment, what could be fleshed out more is how things go from there -- things like 'this happens at Begin+2s' and so on. Some things have already been emulated in the code, but if we hit something that is not possible to do with DOM 2 Events directly, then it's not an XForms question, but a DOM 2 Events one (or an XML Events one if it's simply a question of providing an additional mapping layer). Anyway, I do think it's the use-case that needs defining first, and once we have that, we can discuss how best it would be implemented. Regards, Mark On Mon, Apr 27, 2009 at 12:58 AM, Charles F Wiecha <wiecha@us.ibm.com> wrote: > Hi Jack -- sounds like the "strawman" implementation is the way to > go...frankly, we'll get 80% or more of the benefits from just being able to > show *how* SMIL is integrated with other technologies -- and the details of > the level of functionality will (and should be) secondary at this point. > > So I'd say if you're able to execute simple sequences, dispatch some events > outside of the SMIL markup to control other elements on the page (perhaps > using the XForms dispatch action), and maybe do some simple conditionality > to select the right path inside SMIL then we're probably about there... > > Note that I don't yet have a very specific use case in mind so if you do, > please let us know...and if you think the above is do-able in a reasonable > amount of work I do think it would add very appreciably to the story we can > tell... > > What do others think??? > > Thanks, Charlie > > Charles Wiecha > Manager, Multichannel Web Interaction > IBM T.J. Watson Research Center > P.O. Box 704 > Yorktown Heights, N.Y. 10598 > Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614 > wiecha@us.ibm.com > > > Jack Jansen ---04/26/2009 04:34:13 PM---On 24-Apr-2009, at 22:49 , Charles F > Wiecha wrote: > 3. we brainstormed briefly the role of SMIL in > > > From: > Jack Jansen <Jack.Jansen@cwi.nl> > To: > Charles F Wiecha/Watson/IBM@IBMUS > Cc: > public-xg-app-backplane <public-xg-app-backplane@w3.org> > Date: > 04/26/2009 04:34 PM > Subject: > Re: Minutes for April 21 Backplane telecon > Sent by: > public-xg-app-backplane-request@w3.org > ________________________________ > > > > On 24-Apr-2009, at 22:49 , Charles F Wiecha wrote: > > 3. we brainstormed briefly the role of SMIL in the scenario and await > further inputs from Jack on this point. In general, the demo implementation > would be ready to start using some SMIL Ubiquity implementation within a few > weeks... > > Things are going _very_ slow at my side. We did an Ambulant micro-release > (to get it out of the way), but it turned out to take 2 weeks in stead of > the anticipated 1 day:-( And my other main project is also demanding much > more time than anticipated, plus Fons (the other person expected to be > working on the JS SMIL implementation) has been 100% busy with writing a > paper. > > So, the chances of a "real" SMIL implementation, even with only very limited > functionality, being available within a few weeks is pretty much zero. > > That raises the question of how important SMIL support within a couple of > weeks is going to be for your progress. If it's important we either have to > rig up something based on the strawman implementation I have, or have some > hand-coded javascript as a placeholder. If it's not in the critical path we > could leave it until I have something real working (which I now expect to be > not before end of june, mid july). > > The strawman does have an advantage: it would allow us to experiment with > how we can connect SMIL with the other technologies, probably based on > something like relevance, without bothering too much about code quality, as > we're going to throw it away anyway. But there's a potential disadvantage in > that you might want to use all sorts of esoteric SMIL features (excl comes > to mind) that would need to be implemented in the strawman, with probably > little chance to reuse the code later. > > > -- > Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > -- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com http://webBackplane.com/mark-birbeck webBackplane is a trading name of Backplane Ltd. (company number 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street, London, EC2A 4RR)
Received on Monday, 27 April 2009 09:00:34 UTC