RE: The 'hanlder' element

Converting JPEG to MPEG is not straigth
forward. If we were to do it, it would have
to be done at the head-end then pushed to
the settop - making it latent. Keep in mind
that our low end does nto allow for JPEG
processing unless it is done in the background.
Even then, we would be restricted to small
images. The MPEG support is built in.

Cable standards do not mandate support for PNG
nor JPEG. OCAP does allow it.

I was under the impression that eRR could be
used in a switch statement to identify system
capabilities. If it is not the intent, then we would
need something that could 1) identify system
capabilities 2) offer alternatives based on
system capabilities.

Putting test attributes in the image element
would be a great idea.

foreignObject may still be required since
some proprietary image formats do not
have a mime-typed and are not general
purpose. These must also be able to
identify system capabilities. Is this 
possible in the image element?

-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org]
Sent: Thursday, July 22, 2004 10:24 AM
To: James Bentley
Cc: 'Robin Berjon'; 'www-svg@w3.org'
Subject: 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 14:55:58 UTC