W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

SVG 1.2 Comment: Media

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 24 Nov 2004 21:57:34 -0600
Message-ID: <41A5582E.1080107@mit.edu>
To: www-svg@w3.org

It's not clear to me why this is being introduced in the context of a vector 
graphics specification.  It's also not clear which profiles require this 
functionality.  That should be clearly documented, instead of the vague comments 
about profiles being able to redefine anything they want about what support is 
required (which is what section 12.1.1 says now).

Apart from the fact that I strongly feel that I should be able to implement a 
vector graphics language for web use without implementing audio support, and 
thus feel that this section does not belong in SVG, I have the following comments:


The prose mentioning "SMIL animation features" should link to where said 
features are defined, or at the very least normatively reference a specific SMIL 
version (the former would be far preferable, using a dated link).

I don't see the "volume" attribute defined anywhere.  Nor do I see a "type" 
attribute defined.  Nor "repeatCount".  There is no 'attlist.audio', which is 
referenced by the RelaxNG schema, in sight.  If it's defined elsewhere, it 
should be linked to.

The SVGAudioElement interface does not describe what the "audio" property is, 
whether it must always be non-null or is allowed to be null, what it returns if 
the audio resource could not be retrieved.

There is no link the the SVGMediaElement definition.  I cannot find this 
definition in either SVG 1.1 or SVG 1.2.

The interface definition is inconsistant with that given in Appendix A (and the 
latter is mis-named "SVGAudiolement").

There is no definition of the SVGAudio interface here and no link to the place 
where the definition is given.  One or the other should be present.

I stopped looking at this section at this point, because it's clear that it's 
just not finished.  I'm not sure why it was proposed for last call...

To summarize, neither the content model or the DOM interface is described in 
anything resembling the level of detail that is needed to implement this 
interoperably without reverse-engineering other specifications.  I'd like to 
request that something other than examples be written for this section of the 
specification before it goes to CR, if it is not removed altogether per my first 


Again, please link and/or normatively reference exactly which SMIL features are 
being imported.  "The usual features" just doesn't cut it as a specification of 
UA behavior.

Please link the refs in the attlist.video define to the places where they are 
actually defined.  As things stand, it would take me a good deal of time to look 
up where all those lists are defined, such that I would know what attributes a 
<video> can be expected to have.

I'm not sure what the point of the paragraph after the RelaxNG definition is. 
It's not normative, it's not particularly informative, and it simply sounds like 
the working group trying to convince the world that this section of the spec is 
really OK to have...


There is no definition of exactly what the children of a multiImage element 
should look like.  Defining such things through examples, which is what section 
12.3 does, really doesn't cut it.  Please provide the RelaxNG schema and a lucid 
prose description of the functionality.

Again, please link to the relevant SMIL specifications.


Where are min-pixel-size/max-pixel-size defined?  Please link to the definitions 

Please clearly explain what those attributes do in this context.

What happens if a subImageRef has children?  Are they rendered?


Can a subImage contain a multiImage?


This section, which explains how all this stuff works, should probably come 
after the RelaxNG definitions and after a very brief prose passage outlining the 
overall setup, but before the examples.

It's not clear to me whether min/max-pixel-size may be specified in any units 
desired or only in user units.  This needs to be documented.

Are the ranges defined by the min/max-pixel-size values exclusive or inclusive? 
  That is, if I have two subImageRef children, one with min-pixel-size="1px" and 
one with max-image-size="1px", will both of those children be considered to 
contain the current resolution in their range?  Or will it be neither?  Or only 
one?  If so, which one?

What is the metric used to measure the distance between a range and the current 
resolution, especially for ranges that contain the current resolution (needed to 
resolve conflicts when multiple ranges overlap the current resolution)?


It's not clear to me what the

   dB change in signal level = 20 * log10(vol)

formula means.  Change from where?  The default volume of the element?  If so, 
say so, please.  Clearly this algorithm cannot be applied when vol == 0; that 
should be made clearer.

"all children" should be "all child"


If images are allowed to not be loaded (or even if they're not allowed, since 
DOM access can happen at any time), the specification needs to document the 
behavior of the image DOM interfaces (which allow access to image data, if I 
understand them correctly) in a lot more detail.

Received on Thursday, 25 November 2004 04:02:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC