Re: [Issue 517] Proposal to address nested time containers.

I agree the substance of this proposed resolution.  I would try to make the
final wording just a bit more short and sweet.  [details below at AG::]

At 03:37 PM 2001-07-03 , Ian B. Jacobs wrote:
>Hello,
>
>Based on discussions with Jon Ferraiolo and Dean Jackson at the 
>28 June 2001 teleconference [1] about issue 517 [2], I'd like to
>propose the following to address this question: What do checkpoints
>4.4 and 4.5 mean in the case of nested time containers? The original
>comment [3] from the SVG WG was:
>
>    [Checkpoint 4.4] talks about controlling particular 
>    animations on an individual basis. This is not practical 
>    with SMIL and SVG as this goes against the basic data models
>inherent
>    in the languages. In SMIL and SVG (and QuickTime), there are time 
>    containers which are masters over time-based content such as
>individual 
>    animations. The time container is the master that drives the
>animation 
>    as a slave. The animation just responds to commands such as "update 
>    yourself to what you should look like X.Y seconds into the
>animation". 
>    The only thing that is reasonable is to allow the ability to pause, 
>    accelerate or decelerate the time containers. 
>
>[Editor's note: So far the checkpoint does apply to the SMIL 2 model.
> The SVG WG comments continue]
>
>   However, if you have nested time containers, things can still get
>very 
>   complicated as the nested time containers themselves are just slaves
>to 
>   their parent time containers. Selecting these nested time containers
>would 
>   require extensive user interface work on the part of UA developers
>which 
>   would represent  large amounts of work just to support this
>checkpoint.
>
>Comments:
>
>   - A user agent must provide the required control for each of the
>     content types listed (audio, animations).
>
>   - Checkpoint 2.6 already requires that the UA respect synchronization
>     cues, so if the user controls two pieces of synchronized content
>(one parent,
>     one child, for example), they should behave in a synchronized
>manner.
>
>Proposal:
>
>   - Added to checkpoints 4.4 and 4.5 that when the time frame of one
>element
>     is controlled by the time frame of another element, this checkpoint
>only
>     requires control over the master. This is a sufficient technique
>(but
>     not necessary, as independent control of "slaves" would also
>satisfy the
>     checkpoint).

In the case of a SMIL proper, all actual content is deferred to externally
referenced media objects.  Here it can make sense to play this video object
alone, or that audio track.  But not to pause one alone.  So one can pause [or
stop] whatever is playing.

In a SMIL one could contemplate pausing the ensemble, changing the content
control on some track from "play" to "don't play" and resume the ensemble
without the offending drum track or strobe light flickering in time with the
drum track.  In a multilevel SVG animation, I believe there is no content
control logic comparable to what is in SMIL.

So in that case it could be quite reasonable to consider the whole SVG _one
animation_ for the purposes of 4.4 and 4.5.

Here we may be having communication problems because of the overloading of
'element.'  What one needs to be able to start stop pause and advance is a
separately playable media object.  Not every XML [syntactic] element in the
construction thereof.

Al

>
>   - A user agent may also provide independent control of the "slave"
>element.
>
>   - Add a SMIL example of this to the Techniques document.
>     
>Notes:
>   
> 1) Reference draft: 22 June 2001:
>   
<http://www.w3.org/TR/2001/WD-UAAG10-20010622/g>http://www.w3.org/TR/2001/WD
-UAAG10-20010622/g
>
>The SVG makes an additional comment:
>
>   A SMIL or SVG UA has no way of determining whether an animation can
>be 
>  recognized as purely stylistic. In fact, in presentation-oriented
>languages 
>  like SMIL and SVG, it is often unclear where content ends and styling 
>  begins. It is meaningless to talk about UA not being required to
>satisfy 
>  the checkpoint for animations for purely stylistic effects as this is 
>  almost never recognizable.
>
>Response: That's fine and that means the style part of the checkpoint
>would
>not apply. But that doesn't require any change to UAAG 1.0.
>
> - Ian
>
>
>[1]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0002.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2001JulSep/0002.html
>[2]
<http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#517>http://se
rver.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#517
>[3]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0199>http://lists
.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0199
>-- 
>Ian Jacobs (ij@w3.org)  
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
>Cell:                    +1 917 450-8783
>

Received on Tuesday, 10 July 2001 22:27:29 UTC