RE: SVG12: event base for audio/video/animation elements

Hi, Bjoern-

Thanks for your clarification.

Bjoern Hoehrmann wrote:
| 
| The specification must define what the event-base of an event-value is
| if no event-base element is specified in the event-value for all the
| elements/attributes defined in the specification. Neither the current
| draft nor the text you've proposed achieve that (neither directly nor
| indirectly through normative reference).
| 
| There is nothing difficult about this, for
| 
|   <svg ...>
|     <rect ...>
|       <audio begin="evt" .../>
|       <animation begin="evt" .../>
|       <video begin="evt" .../>
|       <discard begin="evt" .../>
|       <set begin="evt" .../>
|       <animate begin="evt" .../>
|       <animateColor begin="evt" .../>
|       <animateTransform  begin="evt" .../>
|       <animateMotion begin="evt" .../>
|     
| I want to know for each element with a begin attribute when it begins.
| Each element begins when 'evt' somehow occurs on the 
| event-base element,
| per SMIL. So I need to know the event-base for each event-value.

Of course, the 'audio', 'video', and 'animation' elements are not supported
as children of the 'rect' element, so this isn't an ideal example, but I see
what you're driving at now.  Your use of the term "event base" rather than
"Eventbase-element", in conjunction with the various permutations used in
the SMIL specs (e.g. Eventbase-element, event-base element, Event-base
element, eventbase element, eventbase-element) initially clouded the issue
for me.


| The current draft can be read to say the event-base of the <audio> above
| is the <rect>. It can also be read to say it's <audio>. The Working
| Group apparently reads it to say it's <svg>. Yes, I really do think
| having three different interpretations out of two possible
| interpretations is a problem that needs to be addressed.

The implementors on the SVG WG think that the Eventbase-element is clear by
our normative reference to SMIL (with such language as, "The event-base
element is the element on which the event is observed" and "If the
Eventbase-element term is missing, the event-base element is  
defined to be the target element of the animation") and the implicit
descriptions and examples in our spec.  

However, to avoid any confusion, we agree to your request to add further
clarification.  Since we do not wish to normatively redefine or respecify
event-base (for the reason I stated before) we have decided instead to
create an informative section that clarifies the issue for implementors and
authors.

I placed the following wording in 'animation.html', just before <h4
id="ClockValueSyntax">Clock values</h4>, and link to it from the sole
mention of "event-base element", located in the defintion of "event-value".
This in turn is referenced by 'multimedia.html' and 'struct.html' for all
the relevant elements.

"Eventbase-element

This section is informative.  For a normative reference of
Eventbase-element, see the [SMIL Animation] specification.  For declarative
animation or 'discard' elements, the default Eventbase-element is the
animation target, which for elements with an 'xlink:href' attribute is the
target IRI, and is otherwise the parent element.  The default
Eventbase-element for all media elements (e.g. audio, video, animation) is
the element itself.  For all event-values that are prefaced with an
Id-value, the Eventbase-element is the element indicated by that id.
Authoring Note: non-rendered elements such as the audio element cannot
receive user-initiated pointer events, so it is recommended that authors
specify a rendered element as the Eventbase-element for such cases."


| I understand you think that usually when I say there is
| a problem, there probably is none, but in this case I can 
| truly assure you that I think that yes, there is a problem.

It seems you misinterpreted my intent.  I was not questioning your judgement
in raising the issue, but merely asking if the interpretation of the
normative reference sufficed to address your concern.  Clearly, it did not,
and we addressed that as I explain above.  

With this issue, as with all other issues you have raised, we have treated
the question seriously, have researched and discussed it, and have attempted
to take such corrective actions as we saw were needed.  I apologize if you
were left with any other impression.  As I've stated publicly many times
before, your technical abilities and your feedback are very welcome; if we
come to a different conclusion on some issues, please do not take that as a
sign otherwise.

If this does not satisfy your concern, please respond within promptly with
further clarification.

Thanks-
Doug, on behalf of the SVG WG

Received on Thursday, 13 July 2006 04:39:14 UTC