Re: [SMIL30 LC comment] 3.2 ( LC-1808)

 Dear Dr. Olaf Hoffmann ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at www-smil@w3.org if
you agree with it or not before 02 nov 2007. In case of disagreement, you
are requested to provide a specific solution for or a path to a consensus
with the Working Group. If such a consensus cannot be achieved, you will
be given the opportunity to raise a formal objection which will then be
reviewed by the Director during the transition of this document to the
next stage in the W3C Recommendation Track.

Thanks,

For the SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1. http://www.w3.org/mid/200708161601.19842.Dr.O.Hoffmann@gmx.de
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on 3.2 Introduction:
> Hello SMIL working group,
> 
> 
> some comments on
> 3.2 Introduction
> 
> ---------------
> typo?
> 
> 'The examples in this document that include syntax for a host language
> 
> use [SMIL10], [SVG], [HTML4] and [CSS2].'
> ->
> 'The examples in this document include syntax for a host language use
> [SMIL10], [SVG], [HTML4] and [CSS2].' ?
> ------------------
> 
> 'Animation only manipulates attributes and properties of the target
> elements,
> and so does not require any knowledge of the target element semantics
> beyond
> basic type information.'
> 
> -> Information, whether the attribute is animatable or not?
> -> Information, whether the attribute is additive or not?
> -> calcMode paced requires some more information about the
>     meaning of the animated attribute or property, if it is a
>     more complex type to get something related to a paced
>     change with a meaning...
>     For example it is a difference if a list of some numbers
>     represent a vector or just a list of some numbers without
>     a direction or an absolute value as a vector has...
> 
> 
> ------------------
> 
> Bad document structure?
> 
> 'The BasicInlineTiming module is a prerequisite for any profile using
> SMIL
> Animation. The reader is presumed to have read and be familiar with the
> 
> SMIL 3.0 Timing modules.'
> 
> -> Why is the animation section before the timing section in the table
> of
> contents, if the timing section is required to understand the
> animation
> section? 
> (This is included too in the general comment from 2007-08-01)
> 
> 
> ------
> 
> -> It is maybe a good idea to introduce the elements animate and
> animateMotion
> here in the introduction shortly to prepare the reader for typical
> examples
> offered before these elements are really defined. One additional
> paragraph
> would be enough to reduce this problem.


Working Group Resolution (LC-1808):
Dr. Olaf Hoffmann wrote:
> Hello SMIL working group,
> 
> 
> some comments on
> 3.2 Introduction
> 
> ---------------
> typo?
> 
> 'The examples in this document that include syntax for a host language 
> use [SMIL10], [SVG], [HTML4] and [CSS2].'
> ->
> 'The examples in this document include syntax for a host language use
> [SMIL10], [SVG], [HTML4] and [CSS2].' ?\

The sentence

'The examples in this document that include syntax for a host language
use [SMIL10], [SVG], [HTML4] and [CSS2].'

is in fact correct English, and it is what was meant, except that the
reference to SMIL 1.0 is not appropriate: that should be SMIL 3.0.  What
is meant is that those examples that use host language syntax (i.e. every
example that uses actual XML tags as opposed to just an attribute value),
use the syntax of one of the referenced languages.

> ------------------
> 
> 'Animation only manipulates attributes and properties of the target
elements,
> and so does not require any knowledge of the target element semantics
beyond
> basic type information.'
> 
> -> Information, whether the attribute is animatable or not?
> -> Information, whether the attribute is additive or not?
> -> calcMode paced requires some more information about the
>     meaning of the animated attribute or property, if it is a
>     more complex type to get something related to a paced
>     change with a meaning...
>     For example it is a difference if a list of some numbers
>     represent a vector or just a list of some numbers without
>     a direction or an absolute value as a vector has...

The paragraph has been changed to:

"While this document defines a base set of animation capabilities, it is
assumed that host languages may build upon the support to define
additional or more specialized animation elements. Animation only
manipulates attributes and properties of the target elements, and so does
not require any knowledge of the target element semantics beyond basic
type information. Basic type information includes such information as
whether a type supports addition, and whether a list of numbers is just
that, or whether it represents e.g. a set of coordinates.

Note that the host language determines which attributes can be animated."

> ------------------
> 
> Bad document structure?
> 
> 'The BasicInlineTiming module is a prerequisite for any profile using
SMIL
> Animation. The reader is presumed to have read and be familiar with the

> SMIL 3.0 Timing modules.'
> 
> -> Why is the animation section before the timing section in the table
of
> contents, if the timing section is required to understand the animation
> section? 
> (This is included too in the general comment from 2007-08-01)

The Working Group has rearranged the order of the chapters.  This should
resolve this issue.

> ------
> 
> -> It is maybe a good idea to introduce the elements animate and
animateMotion
> here in the introduction shortly to prepare the reader for typical
examples
> offered before these elements are really defined. One additional
paragraph
> would be enough to reduce this problem.

For an introduction to these two elements to be really useful, we would
also need to introduce the relevant attributes and use cases. This is now
done locally with each element. For this version of the specification --
and to maintain consistency over various modules -- we have decided not to
change this.


----

Received on Monday, 29 October 2007 14:12:56 UTC