Re: The 'hanlder' element

On Wednesday, July 21, 2004, 5:39:12 PM, James wrote:


JB> A list is being compiled. If you are referring to Image formats,
JB> JPEG and PNG may be problematic in low-end set top boxes.
JB> However, MPEG I or P Frames are possible (in some).

Is it possible to convert the JPEG or have it displayed using the MPEG
decoder? (just wondering aloud). I know some STB already have PNG
(sometimes in hardware) and some TV standards require it.

JB> One suggestion
JB> would be to allow the 'image' element to reference a 'switch' element
JB> that must resolve to an element capable of inheriting image attributes.
JB> This would allow the 'externalResourcesRequired' attribute to be used
JB> to identify JPEG and/or PNG rendering capability,

(eRR does not do that. It tells the viewer to wait until all resources
are loaded before displaying anything).

JB> as well as MPEG rendering capability.

we are considering adding a media type test attribute to the image
element for 1.2, which we already have on the video and audio elements.
We are also adding switch to a lot more places. Test attributes can
already be used outside of switch, though.

JB> Since many proprietary image formats exist, it may also be necessary to
JB> use 'foreignObject' for additional image rendering.

That is not needed (its not the same as the HTML object element) you can
use the image element for that.

JB> So, to answer your question, the requirement is problematic, and we need a
JB> way to specify additional image formats.

You can specify additional image formats already.

JB> This also shows that some media (i.e. MPEG) can be treated as either an
JB> image or a stream - in consideration of 1.2's media extensions.

JB> One more item. Has there been any thoughts into Copy protection - especially
JB> for streamed media?

Thoughts, yes. A DRM solution for an open format is problematic, and
a 'bozo bit' is seen as adding little value. Copyright information can
certainly be included, ,of course, in the metadata element.

JB> I'll see what I can do to rush the assessment along. Thanks.

JB> -----Original Message-----
JB> From: Chris Lilley [mailto:chris@w3.org]
JB> Sent: Wednesday, July 21, 2004 9:28 AM
JB> To: James Bentley
JB> Cc: 'Robin Berjon'; 'www-svg@w3.org'
JB> Subject: Re: The 'hanlder' element



JB> On Wednesday, July 21, 2004, 4:38:56 PM, James wrote:


JB>> We are considering SVG Tiny 1.2 as part of our assessment, and yes it
JB>> does solve many issues that were raised when we implemented to 1.1 Tiny.
JB>> Some issues still remain.

JB> It would be helpful to have a list of them, would that be possible?

JB>> Many of these issues center around interactivity,
JB>> image formats, conditional processing and external reference . We would
JB> also
JB>> like some restrictions relaxed and impose others.

JB> Is it the requirement to support two particular formats that you find
JB> problematic, or the lack of other formats with mandated support?

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

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

JB> In that case I encourage you to track SVG Tiny 1.2 as it moves through
JB> Last Call. Tell us how it meets your needs and how it doesn't.

JB> We would also be very interested in MicroDOM implementation experience.







-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Thursday, 22 July 2004 12:23:59 UTC