RE: The 'hanlder' element

You are correct, I am confusing externalResourcesRequired with
requiredFeatures.
However, this statement:
"Only feature strings defined in the Feature String appendix are allowed."

may be a bit too restrictive. and requiredExtensions has this verbiage:
"The requiredExtensions attribute defines a list of required language
extensions."

I'm wondering if this is sufficient to indicate whether or not JPEG, MPEG,
DVR, VOD, DOCSIS, TCP and other "resources" are available. I understand
that "resources" is an overloaded term. I suppose my confusion is a
combination
of "resources" overloaded meaning and:

"Attribute externalResourcesRequired is available on all container elements
and to all elements which potentially can reference external resources. It
specifies whether referenced resources that are not part of the current
document are required for proper rendering of the given container element or
graphics element."

I was assuming that this was the proper place to indicate "resources" that
are required for
"proper rendering", such as JPEG decoder. I can also, falsely, assume that
this may extend to
presence of RTSP or DSM-CC for streamable media control (albeit this is
introducing
implementation detail - but it will be required to account for differing VOD
implementations).
At least for RTSP, it can be part of the URI (I'm assuming again). But I'm
not sure on
DSMCC and this has no bearing on digital-video-recording (DVR). Perhaps a
'metadata'
or 'foreignObject' element could describe the requirements - then
'requiredExtensions'
can simply reference the object (I'm including 'metadata' because it does
not require a
bounding box).  Is this the intent of the spec? A bounding box (viewBox,
viewPort,
etc.) would be necessary for images, and may be helpful for streamed media.

We use an image that is similar to a bitmap, with much less header
information. It is
compressed in a proprietary manner. Unfortunately, this image has been in
use for years -
as we advance to using new technologies, we must be willing to accept this
format to
support backward compatibility. I suppose we could call it a bitmap, but
that would
ceratinly confuse people - being that its proprietary, I don't know that we
would release
the compression scheme and format, even though the image may be short lived
(approx.
5years). Any suggestions? Is 'foreignObject' a good place for this
extension?


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org]
Sent: Friday, July 23, 2004 10:34 AM
To: James Bentley
Cc: 'www-svg@w3.org'
Subject: 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 14:01:26 UTC