Re: The 'hanlder' element

On Thursday, July 22, 2004, 8:44:40 PM, James wrote:

JB> Converting JPEG to MPEG is not straigth
JB> forward.

I was just wondering out loud.

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

I was thinking of MHEG5

JB> I was under the impression that eRR could be
JB> used in a switch statement to identify system
JB> capabilities.

I think you are confusing it with requiredFeatures and
requiredExtensions.
http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing


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

Okay.

JB> foreignObject may still be required since
JB> some proprietary image formats do not
JB> have a mime-typed and are not general
JB> purpose.

Yeah, lack of mime types is a problem. Which image formats are you
thinking of?

JB>  These must also be able to
JB> identify system capabilities. Is this 
JB> possible in the image element?

JB> -----Original Message-----
JB> From: Chris Lilley [mailto:chris@w3.org]
JB> Sent: Thursday, July 22, 2004 10:24 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, 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).

JB> Is it possible to convert the JPEG or have it displayed using the MPEG
JB> decoder? (just wondering aloud). I know some STB already have PNG
JB> (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,

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

JB>> as well as MPEG rendering capability.

JB> we are considering adding a media type test attribute to the image
JB> element for 1.2, which we already have on the video and audio elements.
JB> We are also adding switch to a lot more places. Test attributes can
JB> 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.

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

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

JB> 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 -
JB> especially
JB>> for streamed media?

JB> Thoughts, yes. A DRM solution for an open format is problematic, and
JB> a 'bozo bit' is seen as adding little value. Copyright information can
JB> 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
JB> 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
JB> 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 Friday, 23 July 2004 12:33:42 UTC