RE: The 'hanlder' element

We are considering SVG Tiny 1.2 as part of our assessment, and yes it
does solve many issues that were raised when we implemented to 1.1 Tiny.
Some issues still remain. Many of these issues center around interactivity,
image formats, conditional processing and external reference . We would also
like some restrictions relaxed and impose others.

Thank you for the information on MicroDOM. I am very curious to discover
how well this matches up to what we have implemented. As always, we would
seek to match up with standards wherever possible.

Also, thank you for the consideration. I am confident that the problems will
be solved, but I am concerned that we will travel too far down a development
path that diverges from the specification.

-----Original Message-----
From: Robin Berjon [mailto:robin.berjon@expway.fr]
Sent: Wednesday, July 21, 2004 3:52 AM
To: James Bentley
Cc: 'www-svg@w3.org'
Subject: Re: The 'hanlder' element



James Bentley wrote:
> I'm currently preparing an assessment of SVG Tiny and SVG Basic
> for TV. As you mentioned, the platforms are very diverse. Our
> low end target is 20MHz CPU with less than 1.5MB of RAM - for
> video, OS and other resources. Our high end is around 200MHz
> with substantially more RAM (though no where near the capability of
> today's desktop PC). With this constraint, there is not enough room, or
> processing power for full scripting support, full DOM support and
> extensions for set top control and application deployment.

I never considered full DOM support -- even on desktops people would 
rather not have that. I'm thinking of the newer MicroDOM that we've been 
busy specifying, and that is the basis for JSR-226, soon to be found in 
many mobile devices. It can be implemented in a *lot* less than the DOM.


> Though the low end is extremely under powered, its graphics capability
> is, in many instances, much better than a mobile phone. Even the low-end
> can produce Gradients (very easily in the vertical plane). Additionally,
> set tops support MPEG rendering - in a stream or, in some cases, in
stills.
> Further, more audio formats are available.  I'll address all these
problems
> in a future message (once my analysis is complete).

Have you looked at SVG Tiny 1.2? It supports gradients (with a bit of 
subsetting). It also support video and audio. To me it seems like a good 
match for STBs, though perhaps not some of the smaller ones.


> As for DOM3 key events. It appears that the mark up may be (please excuse
> any bad form)
> <rect onkeydown="doSomething()"/>
> 
> or
> <set begin="r.keydown" ...>
> 
> but neither instance allows you to listen for specific keys (there is no
> way to target a specific key - 'U+001b'). If there is, an example would be
> nice.
> Otherwise, it would require script to access the keyIdentifier as well as
> the state
> of the shift, alt, control and meta attributes. What would solve our
current
> need is for the handler to allow something like this:
> 
> <handler type="image/svg" ev:event="keyEvent:'U+001b'">

As Dean said, we've been discussing making SMIL's accessKey more 
powerful (though not with that syntax), though we have so far discarded 
it because SMIL is not under our control. It would seem unlikely to be 
to make it into ev:event because that's a case where one typically has 
script -- but as you say you would prefer SMIL anyway, you probably 
don't mind if it makes it into SMIL and not into XML Events.


> Sorry for the typo in the subject line (just noticed it).

That's hardly a problem :)

-- 
Robin Berjon

Received on Wednesday, 21 July 2004 10:50:52 UTC