W3C home > Mailing lists > Public > public-xg-app-backplane@w3.org > April 2009

Re: Minutes for April 21 Backplane telecon

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Mon, 27 Apr 2009 09:59:54 +0100
Message-ID: <ed77aa9f0904270159x3ead0ff7ne517b2c20142d25e@mail.gmail.com>
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

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.



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



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:50:45 UTC