Disposition of comments for the SYMM Working Group

12. Please consider XForms 1.1 submission

XForms 1.1 contains significant extensions and clarifications to submission
processing and could be used as a pattern for SMIL 3.0 rather than
submission in XForms 1.0. XForms 1.1 is now concluding Last Call and
should enter CR shortly and hence could be used in a Last Call SMIL 3.0
Working Draft at that time.

14, If multiple state elements are desired, then perhaps renaming them
"instance" and introducing the containing "model" element would further
alignment with XForms.

8. Additional event required for data model deletion?

If delete is in fact supported as mentioned above, will another event be
required to notify authors on deletion? If so what notation will be used
to refer to the deleted node since it no longer exists?

11. Are events supported in SMIL 3.0 submission?

Section 15.7.3 indicates that SMIL 3.0 submission follows the design of
submission in XForms -- does this include the events in XForms submission
as well? If so, do they follow XML/DOM event processing?

1. Use of the "expr" attribute name is too generic

We understand that the "expr" attribute functions like a gating condition
on the execution of a SMIL element which otherwise is under the control of
the normal SMIL timing mechanism. "expr", meaning "expression", seems to
us to be too generic a name for this function as the meaning of the
expression in terms of the overall control logic of SMIL is not indicated
by this choice of name. In XForms 1.1 we have introduced the "if"
attribute which, although it's function may not be equivalent, could be
considered as an alternative name for this attribute.

Hello SMIL working group,

this does not look like an accurate method to round:

'The mathematical definition of rounding is:
coerced-integer-value = Math.floor( interpolated-value + 0.5 )'

-> There are different mathematical definitions for rounding.
This is a biased rounding because number=integer+0.5 is always
rounded up (for other cases the rounding definitions are the
same). This is not an accurate rounding method.
This means, over a larger number of rounding the average
rounding error is not zero.
For an unbiased rounding, for example for even
integers number is rounded down, for odd up...

example:
value, top eq. 'rounding' , unbiased rounding (round to even)
0.5 1 0
1.5 2 2
2.5 3 2
3.5 4 4
4.5 5 4
5.5 6 6
6.5 7 6
7.5 8 8
8.5 9 8
9.5 10 10

average

5 5.5 5


I would like to suggest to use the unbiased or
'round to even' method ...

Greetings,

Section 17.4.8 Media Object Modules of the SMIL 3.0 specification
states that Vorbis and Theora MIME types are application/ogg. This is
no longer the case, as the Xiph.Org Foundation has deemed necessary to
change this to increase interoperability between the many hardware and
software implementations that deal with its different formats.

Per the MIME Types and File Extensions Recommendation[1], which is in
the process of becoming a RFC, Theora MIME type is video/ogg and
Vorbis MIME type is audio/ogg.

Is it possible to rectify the SMIL 3.0 specification while it's still
on the Last Call stage?

Is it also possible to modify this section as to add another
royalty-free format as either optional or required for user-agents to
implement? We would like to suggest support for the Speex[2][3] media
format, as its speech-optimized qualities allow for many uses over the
Web where human voice is required.

Possibly, an entry like
"the following royalty-free media formats are suggested to be supported:
* Ogg Speex audio (audio/ogg)"
may be included.


Thank you for your attention,
Best regards,

Ivo Emanuel Gonçalves
Xiph.Org Foundation

[1] http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
[2] http://speex.org/
[3] http://en.wikipedia.org/wiki/Speex

Hello WG,

It was brought to my attention the Mime types for the Xiph media are
incorrect.

"These are great news. Unfortunately they put the old MIME type
application/ogg. As of recently, we (Xiph) decided [1] to go with
video/ogg and audio/ogg+vorbis."


The list of MIME Types and File Extensions can be found here:
http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions

Keep up the great work, you guys that build the standards are the unsung
heroes of the Web :)

Jose Ramirez

4. Missing delete action?

We note the use of newvalue to create a new entry in the data model...is
delete also supported? Once created, are data model entries able to be
deleted by other means?

5. How is the position for new data model entries determined?

The "ref" attribute is used to specify the position of new entries in the
data model, as described in Section 15.6.3: "Therefore, name is used to
give the name for the new item and ref specifies where it is inserted."
Where is the new entry created relative to the entry given in "ref" -- as a
child element, and if so where in the possibly existing set of children.
If as a sibling, before or after the ref'd item?

Does the SMIL 3.0 data model have the notion of order as in XML or not,
perhaps depending again on the language profile used (some environments
such as ECMAScript or Servlet attributes may not support the notion of
document order)?

13. Support for replace=instance on submission

It appears that only a single state element is allowed in SMIL 3.0. If
this is the case, is replace=instance also supported on submission? If so,
then only the single, original "instance" in the state element could be
targeted -- making some use cases difficult. A common use case is to query
for data that is dependent on some values first obtained from the user (for
example a US state) then to return the list of valid city names in that
state in a second instance. Lacking support for multiple state elements
this pattern would be difficult. XForms 1.1 does allow targeting subtrees
of an instance hence the author could partition the single data model to
support this pattern by convention, albeit with more difficulty than if
multiple state elements are supported.

Hello www-smil,

While reading

Synchronized Multimedia Integration Language (SMIL 3.0)
W3C Working Draft 13 July 2007

I noticed several instances of the word 'must' in informative sections. This is problematic, due to the common usage of 'must' as a conformance requirement in W3C specifications.

Please either

a) reword these sections to avoid 'must', or
b) add clarificatory wording regarding use of 'must' in the specification as a whole and noting any relationship to RFC 2119, or
c) consider making some of the informative sections normative, if 'must' is indeed used as a conformance requirement in some cases

Hi, SYMM WG-

As the SVG WG wrote to you in a liaison in May 2007 [1], the
systemLanguage attribute of the 'switch' element [2] does not adequately
account for quality-values in Accept-Language strings. The result of
this is that users who have assigned quality values to their language
acceptance are unlikely to get the ideal language option, even if one is
available. The boolean nature of 'switch', in this regard, should be
amended to evaluate at a more discrete level for systemLanguage.

We have proposed an alternate algorithm [1] which, while slightly more
complex, does yield the ideal results, even in combination with other
test attributes. However, this feedback does not seem to have be taken
into account in SMIL 3.0. Any algorithm that solves this issue is fine
with us, but the issue should be solved in SMIL 3.0.

SVG relies on the SMIL definition of 'switch' for use in our own
specification, and we need proper i18n. We are happy to work with you
to come up with a solution.


[1] (member-only) http://lists.w3.org/Archives/Member/symm/2007Apr/0016.html
[2]
http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-content.html#adef-systemLanguage

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Hello SMIL working group,

some comments on chapter 8


8.3.1


'inherit
The effective value of this attribute is used.'

-> What is an 'effective value'?
-> Define or reference definition...
-> or something like this:
'inherit
The textWrapOption value of the parent element
is used.'?

--------------

typo?

'This time is defines as being relative ...'
->
'This time is defined as being relative ...'?


---------

typo? (missing whitespace)

'no preceding tev/clearelement'

->
'no preceding tev/clear element'

---------------

'Examples'

-> shouldn't this be inside the informative box?

---------------
8.3

smilText element content:

'The smilText element may contain character content.'
->
'The smilText element may contain the elements tev, clear, br
or character content.'?

---------------------------

8.4

- The p element in XHTML has a semantic meaning
of a paragraph and has nothing to do with styling, but
with the meaning of the content. It is maybe not a
good idea to define it here without a meaning just for
styling purposes. Wouldn't it be sufficient to note
that a div can be within a div (but maybe not
more then one level of nesting)?

- Another idea to get a little bit more meaning
to the meaningless elements of this module is
to add for example an attribute to smilText, div and span
like textSemantics or textMeaning with a comma or
space separated list as value with list items
like h'digit', p, q, abbr, em, strong, pre, article, abstract,
poem, stanza, line etc
(some more are available in the drafts for 'HTML5' or XHTML2),
partly similar to (X)HTML elements with semantic meanings
or of semantic structures, currently not represented with
(X)HTML elements, but nice for SMIL presentation.
Author defined semantic value fragments could start with
'-' for example to expand this a little bit.
Of course authors can use (X)HTML right
from the start to avoid meaningless text
elements, but SMIL adds an additional
feature like timing to the text, therefore there
might be a reason to use this instead of
(X)HTML.

Therefore one can write
<div textMeaning="stanza em"> ... </div>
or
<div textMeaning="p poem -concretePoetry"> ... </div>

This is not much more to implement, because there
is no need to have a default styling for all these
things, anyway the meaning of the content is
machine readable and identificable as an author
expects from a good markup language.
If the author needs more than this
'minimal semantics', XHTML can be used, but even
with ideas like 'microformats' this will not be
much better for many text types as poems...
And if CSS is available, authors can use this
for styling too, using a selektor like
div[textMeaning~="-concretePoetry"] or
the styling attributes of smilText of course.
Anyway these presentational attributes move
smilText a little bit in the direction that
presents text as a graphical object, as it is
in SVG, is this intended? If not, it would
be sufficient to style it with CSS, isn't it?




-------------------------
div element:

'This element accepts as content zero or more characters to which the
specified styling is applied.'
->
'This element accepts as content p or span elements or zero or more characters
to
which the specified styling is applied.'?

-> etc for the p element ...?

----------

-> I think, textWrapOption is useful for div, this avoids further
fragmentation of text, if the author needs for example a container
of non wrapping text as pre in XHTML inside a larger text
fragment. I think, without the textWrapOption for div the
author has to divide his text in three smilText elements to
get the same effect. But often this three fragments of text
belong together as one text inside one large text container.

---------------------

8.4.1
Example

typo?

"... as is shown in line 30'w ..."

-> what is the meaning of 'w?

'Finally, the text element on line 35 illustrates that it is
possible to mix in-line and external text in a single document.'

-> line 36?


------------------------------

8.5.1

textRate


-> Because luckily the textFontSize is given in
absolute or relative sizes, units like em, ex,
glyphs are much more useful for authors to guess
some useful rate as px, because the relation between
the size of a glyph and a pixel is not known by
the author.
To get something useful, we have to know, how
reading works, maybe we need something like
words per second to get an even more useful
guess for a textRate appropriate for a slow reader
as glyphs per second...
Maybe one has to ask some experts on psychology
or behaviour research or something like this to
get some information about a useful unit for
textRate concerning typical reading strategies and
rhythms including a hint for authors about a
useful value range for textRate for
accessibility reasons.
Looking for this at wikipedia something like
word fragments per second can be a useful
unit - a word fragment is either a complete
word if below say 10 glyphs or for longer
words a fragment of the word of about 7
glyphs.
A typical range would be around
2-5 word fragments per second for normal reading.
Because it is more difficult to read moving
text or specific fonts or sizes, this can
be used as a hint for authors for a maximum
value of a useful textRate.
This applies only to alpabetical scripts,
only in parts to syllabary or Scripts
using symbols. Maybe for them the approximation
withs glyphs per second is more useful...

Of course to get a smooth motion or a paced
change of text position, viewers might
transform the textRate again in an
average value in px per second, because the
viewer knows the size of a glyph in px and
can determine a presentational textRate similar
as this is done for font-size in CSS.


-> lines per second continuous or in jumps are
not very useful too, because the number of
glyphs or words in a line depend on the font
size and authors cannot guess some useful
rate in lines per second, except maybe for
poems with short stanzas and lines, in such a case
it maybe very useful to give information
about the rhythm of the poem with a textRate
in lines per second, else this normally will
reduce readability of the text...

-> for accessibility reasons there should be
a simple method for readers to manipulate
this textRate to their personal abilities in
each user agent, else such a feature is
more a method to torture readers...
(I really dislike such moving text sections
in movies in TV with tooooo tiny fonts and
toooo fast motion, one has to manipulate the
player and has to use a lens/magnifier to
separate the glyphs from noisy pixels ;o)

Hello SMIL working group,

some comments on chapter 13


13.2

'An alternative to Timesheets is XHTML+SMIL...'

-> reference XHTML+SMIL...
-> this one? http://www.w3.org/TR/XHTMLplusSMIL/
(but this is for SMIL2.0)

----------------
13.3

-> Add required title element to the XHTML example...
-> Do not need all SMIL elements the prefix 'smil:'
not just the first one?
Either one has to put the xmlns attribute into the
timesheet element, but then it is not needed in
the html element anymore...
-> Why is the timing inside the XHTML document while
the module is called 'External Timing'? Seems to
be no ideal example for 'External Timing'?

---

typo?

'<!DOCTYPE htmlLIC "-//W3C//DTD XHTML 1.0
Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">'?

->
'<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">'?


----------------

13.7.2

'The following example illustrates how the animate element can be
used to animate CSS attributes of elements of the host language.
<smil:timesheet>
<seq>
<item select=".Slide" dur="15s">
<par>
<item select=".Bullet" beginInc="3s">
<animate select=".Bullet" attributeName="marginLeft" values="200;0"
dur="1s" />
</item>
</par>
</item>
</seq>
</smil:timesheet>'

-> CSS properties or really attributes? If attributes reference an example
language...
-> 'attributeName="marginLeft"' which language has a CSS
property 'marginLeft'?
If this is defined in SMIL, this is maybe a good indication to reference
the definition here again ;o)

-----------------

13.8

Index Function

-> Add required title element to the XHTML example...

-> wrong/senseless structure or example:

'<head>
<!DOCTYPE htmlLIC "-//W3C//DTD XHTML 1.0
Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:smil="http://www.w3.org/2007/07/SMIL30/Timesheets">
<head>
<smi:timesheet>
<par>
<excl>
...'

->
'<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:smil="http://www.w3.org/2007/07/SMIL30/Timesheets">
<head>
<smil:timesheet>
<smil:par>
<smil:excl>
...'?


-> missing required alt attribute in img elements, if they are from XHTML as
indicated in the example

-> a practical problem with this example is, that the large images are all
loaded with the document at once, therefore the thumbnails are useless,
if all images are loaded anyway, this is ineffective for the purpose of
an image gallery and from the point of produced traffic, because the
user expects to have a choice to choose and load an image or not...


-----------

General:

- why not to use an XML processing instruction to reference the
timesheet as a stylesheet?
<?xml-stylesheet href="timesheet.smil" type="application/smil+xml"
title="a timesheet" alternate="yes" ?>
then it is not needed to use another namespace in the XHTML-document
and it is possible to use it alternatively or additionally to CSS...

As a possible application:

a) example.xhtml contains references to CSS-files and to timesheet-files
either with xml-stylesheet processing instructions or the link element.
b) all styling is in external files, some for CSS, some for timesheets,
depending on the processing instruction or the rel attribute of the link
element, the different stylings can be combined or used alternatively.
c) the user/reader can select the desired styling within the user-agent
depending on the defaults of the author or additional selectivity
possibilities of the user-agent

- because the author has not to mix different XMLs in one document and
does not have to put SMIL code directly into the main document,
the document still validates with an 'ordinary' validator or in the case of
XHTML can still be served as text/html for backwards accessibility, if an
outdated viewer is not able to interprete application/xhtml+xml.

- example for a complete external document with a timesheet missing

- is it already planned/done to add ':timed-inactive' to a CSS3 module?
If not, how to use it in a 'valid' CSS-file?

Hello SMIL working group,

the attributes related to opacity in SMIL as
mediaOpacity or mediaBackgroundOpacity etc currently use
values given in percentage.
-> Isn't it useful to use opacity values between 0 and 1 as
in CSS(3) and SVG for compatibility reasons and easier usage
for authors and developers and avoiding confusion with values
of opacity related attributes or properties in different languages?

Hello SMIL working group,


I think, I found a few problems with this module.

a) General definition

'The SMIL MediaPanZoom module integrates the functionality of the SVG viewBox
attribute and adapts it for use within the SMIL media framework.'

I think, it is in the current definition only in some points related to the
SVG viewBox:


'The value of the viewBox attribute is an ordered list of four numbers,
separated by whitespace and/or a comma:'

- This indeed fits to the SVG viewBox.

But:

' width
A non-negative length value (using CSS2 pixel or non-negative percentage
values)
that defines the horizontal dimension of the viewBox. If pixel notation is
used,
the 'px' suffix may be omitted. A negative value is an error. The default
value of
width is auto.'

- This does not fit to SVG and not to the previous description, because the
value is not a number anymore if it can contain the unit 'px' or can be noted
in percentage. If the default width is 'auto', this is neither a number, nor a
percentage value, nor a length value (a number and a unit).
This section is inconsistent in itself and 'width' and 'height' are not
consistent with the SVG definition of viewBox.




Comparison with SVG:

-> viewBox on an image element for example does not
work in SVG as described here for SMIL3.
In SVG 1.1 or SVG tiny 1.2 CR it is noted:
'i.e. the 'image' element has an implicit 'viewBox' of
"0 0 raster-image-width raster-image-height"'
Similar thing we get in SVG tiny 1.2 CR
for the elements video and animation.
To conclude, the viewBox described in this draft does not
have much more in common with the SVG viewBox element as the name.
It works more or less in a similar way for the elements svg and symbol.
Maybe it is a good idea to change the name of the SMIL attribute to
avoid confusion, for example what about zoomBox?



b) The example contains errors:

'<smil ...>
<head>
...
<layout>
<root-layout height="200" width="300" backgroundColor="red" />
<region id="B" top="0" left="0" height="50" width="75"
backgroundColor="blue" />
</layout>
</head>
<body>
<seq>
<ref id="R0" src="table_233x150.jpg" viewBox="0,0,50,75" dur="20s"
region="T" fit=""meet" >
<animate attributeName="viewBox"
values="(25,20,50,75); (45,55,50,75);(140,40,50,75);
(35,0,100,150); (0,0,100,150);"
dur="20s" />
</ref>
...
</seq>
</body>
</smil>'

- the animate element, the values attribute:
-> The last ';' is wrong
-> the '(' and ')' are not part of the viewBox attribute or the values
attribute,
therefore this is wrong too.
-> values="25,20,50,75; 45,55,50,75;140,40,50,75;35,0,100,150; 0,0,100,150"





c) Animation problem (?)

-> What about calcMode paced for viewBox?
Due to some wrong formulas in the SVG tiny 1.2 CR
I already did some calculations about this for several
attributes with lists of numbers or even with a mixture
of values of different units. viewBox is either a list of
two vectors or a list of one vector and two scalars.
There can be a paced change of the value of a viewBox.
The procedure can be to expand the value consisting of
4 numbers to a list of 4 points or vectors to the corners
of the viewBox. For each point or vectors a paced change
can be gained, using the euclidian distance. If this is
fulfilled, this results in a paced change of each point
of the viewBox. But because each corner needs to be
animated separately, this is no interpolation between the
given values anymore, therefore the condition of calcMode
paced is not fulfilled, to interpolate between the values.
Therefore we can be pretty sure, that there is no
behaviour completely consistent with the definition of
calcMode paced.
What is the expected correct behaviour? Fallback to
calcMode linear?

Hello SMIL working group,

some comments on chapter 10

10.3

'The smil element can have the following attributes:
id
The id attribute uniquely identifies an element within a document.
Its value is an XML identifier. ...'
(this and other attributes defined here)

-> only the smil element or an element within a document?
any element?

-> what about xml:id, is there a plan to introduce this
more general identifier in SMIL? This seems to be
useful, especially for SMIL, combined often with
other XML host languages...

-> it is maybe useful to combine attributes usable on
all elements with a shortcut and to reference these
common attributes in the element specification.
This could be done similar to the HTML4 recommendation
for example, where all applicable attributes are listed
for each element in the element definition and
referenced if not defined with the element itself.

-> it is a little bit confusing that some attributes
are defined here (only) for the smil element, but
used in examples or in some profiles for other
elements too. For a 'naive' reader it is not quite
clear, how this really works, because it is not
explained (here).

-------------------------

'The smil element can contain the following elements:
head
body'

-> an arbitrary number of head and body elements
or exactly one head and one body or a maximum of
one head and one body?

Section "18.4.8 Required MIME Types", part of the SMIL 3.0 Mobile
Profile, indicates:
[[
* audio/basic [MIME-2]
* Ogg Vorbis [VORBIS]
* image/png [PNG-MIME], [PNG-REC]
* image/jpeg [MIME-2], [JFIF]
]]
http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-mobile-profile.html#q14

Requiring the use of PCM and Vorbis in the mobile environment might be
difficult for two reasons:
- it *seems* that Vorbis requires more CPU to be decoded than a format
like AAC, thus rendering its use in a mobile environment more
problematic.
- 3GPP and 3GPP2 already adopted AAC as their audio codec (+ some AMR
speech codecs). It's hard to imagine the mobile industry willing to
switch to a different format now.

So, while I certainly don't want to suggest that the Mobile profile must
require support for AAC, I wonder if the current proposal will be
welcome by the Mobile industry...

Regards,

Philippe

PS: I'm copying Ivo Emanuel Gonçalves and Dominique Hazael-Massieux
since they might have some input or comments.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 1
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:

8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment:
smilText does not define the xml:lang attribute. Thus there is no way to indicate the language of a piece of text. This is a significant limitation, since many rendering, text processing, and text selection applications depend on language identification. Please add the xml:lang attribute.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 2
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment: smilText defines the attribute 'textWrapOption'. No indication is given as to how text wrapping works. In particular, the breaking options don't match the more mature ones that appear in CSS3 (see:http://www.w3.org/TR/2007/WD-css3-text-20070306/#text-wrap)

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 7
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment:There is no way to deal with vertical text with the various layout/styling options?

Prior SMIL specs have introduced many namespaces:

http://annevankesteren.nl/2006/03/smil

It seems that SMIL 3.0 adds at least 63 more to this list:

http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-modules.html#smilModulesNSSMIL21ModuleXMLNamespace

It says that:

The XML namespace identifier for the complete set of SMIL 3.0 modules,
elements and attributes, are contained within the following namespace:

http://www.w3.org/2007/07/SMIL30/

...but this is not correct. Namespaces in XML are opaque strings. [1] The
following are all completely different elements:

<smil xmlns="http://www.w3.org/2007/07/SMIL30/"/>
<smil xmlns="http://www.w3.org/2007/07/SMIL30/AccessKeyTiming"/>

You are effectively forcing implementors to ignore the namespace
altogether or use some other means that to deal with the 174 different
namespaces in SMIL. As I understand it, it's also effectively impossible
to write a RELAX NG schema for SMIL 3.0 because it uses multiple
namespaces.

It is not appropriate to have several namespaces for the same language.
Even with a new version of a language, if it is intended to be backwards
compatible (work in UAs that only support an older version of the
language) it should use the same namespace. XHTML has only one namespace.
SVG has only one namespace. MathML has only one namespace. And so forth.

Given that there already are 111 different namespaces for SMIL prior to
SMIL 3.0, I would suggest that SMIL 3.0 clears this up by introducing one
new namespace that is to be used for all future revisions of SMIL:

http://www.w3.org/ns/smil

...and use a separate attribute to deal with module identifiers (e.g.
module="AccessKeyTiming") if necessary.

[1] http://www.w3.org/TR/REC-xml-names/#NSNameComparison

We are pleased to see the inclusion of smilText modules.

http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html

This will make it easier for people to furnish captions with their
presentations that users can actually use.

This is the only comment the Protocols and Formats Working Group found
to make on this Last Call.

http://www.w3.org/2007/09/12-pf-minutes.html#item05

Al

/chair, PFWG
http://www.w3.org/WAI/PF

2. Relationship between language profile and execution context not clear

Section 15.5.3 states that "The SMIL 3.0 Language Profile specifies that
XPath 1.0 is used as the expression language. " This section also
describes the potential for other expression languages to be used with SMIL
3.0. Perhaps there is just a wording change required in the first sentence
to clarify that XPath 1.0 is the preferred or default expression language.

In addition, the description of the XPath evaluation context being out of
scope is not clear -- perhaps a link to the defined language profiles would
clarify where the expression context and other issues relevant to XPath are
defined.

3. Are attributes supported in the SMIL 3.0 data model?

We don't see examples where attributes are used or supported in the SMIL
3.0 data model -- for example in the setvalue action. Please clarify
whether SMIL 3.0 supports only elements or attributes as well. If
attributes are supported, will a setvalue that references a non-existent
attribute also create that attribute as it does in XForms?

6. Section 15.6.5 additional data model examples would be quite useful.

Additional examples in this section could be provided to clarify some of
the questions raised above -- e.g. the support for attributes, insert
position, whether delete is supported etc.

7. In Section 15.6.6 do we assume XML/DOM event processing?

It is not clear whether the events listed, stateChange and
contentControlChange, follow DOM/XML event processing including
bubble/capture processing etc.

9. Multiple contentControlChange events dispatched?

There are two signatures for the contentControlChange event, one that fires
on any change and the other that indicates a specific change. Will
application authors in general receive both events for each change?

10. Section 15.6.6 namespace terminology

The phrase "Rationale: Raising the stateChange event on the state element
instead of on the data model element itself allows for external data models
(which have a distinct xmlid namespace) and on non-XML data models
(depending on the expression language)." refers to distinct xmlid
*namespaces* when probably what is meant are distinct xmlid *spaces*.
Seems not to be a namespace issue rather one of allowing for distinct XML
documents each of which would have its own space for IDs.

15. Synchronous or asynchronous submission?

Is submission synchronous in SMIL 3.0 as in XForms 1.0? If so, what is the
behavior of the main timing control cycle during submission -- is there the
potential for blocking user or other interaction/presentation unacceptably
while waiting for a response to a submission? What is the behavior of
submission notification events relative to the execution of normal SMIL
timing behavior, e.g. are submission events queued for execution and if so
with what relationship to other SMIL processing?

Hello SMIL working group,

it is the first time I read (almost) a complete
SMIL draft (not just the timing and animation
sections) and I had some problems with the
order of explained features.
It happens often, that elements or attributes
are used from later sections/modules without
any reference or explanation. This makes
understanding much more difficult as needed
and readers often have to search (and find
by chance or not, leaving it open, if something
is missing or that there maybe inconsistencies)
useful definitions of used features.
This happens more often in informative section,
but this is not consequently avoided in normative
sections too...


a) General structure
We have change the spec to have a more intuitive structure to reduce the amount of references to things which aren't defined yet.
- About SMIL 3.0
- Modules
- Structure
- Media Object
- Timing
- Content Control
- Layout
- Text
- Linking
- Metainformation
- Transitions
- Animation
- State
- Time Manipulations
- External Timing
- DOM
- Scalability Framework
- the rest (all profiles) should be the same

There will be also an Index for attributes, elements and modules provided to ease readers.

b) General structure, styling and wording inconsistencies

We will homogenize styling in the spec especially focusing on sections marked as 'This section is informative' or 'This section is normative'.
We will add a paragraph in the introduction explaining how informative and normative sections are styled (and which classes are used).

Hello SMIL working group,


some comments on
3.6.4 Simple animation functions specified by from, to and by


'by animation'

'... This may only be used with attributes that support additive
animation. ...'

-> What happens if a nasty author uses it anyway with non-additive attributes?
Is in such a case simply the additive behaviour ignored, the animation is
equivalent with a values animation using the two values '0' and vb and
additive="replace"? Or is the complete animation ignored as nonsense?
I suggest the first behaviour...


'Normative: A by animation with a by value vb is equivalent to the same
animation with a values list with 2 values, 0 and vb, and additive="sum".
Any other specification of the additive attribute in a by animation is
ignored.'


-> A certain uncertainty came up for some people, what '0' means in this
paragraph. Sure, for attribute values consisting of a simple number or integer
this can be identified simply as the number zero, but for more complex values
there seems to be a gap of imagination ;o)
In SMIL this happens too for example for animateMotion, animateColor or an
animation of an attribute like viewBox. Values of animateMotion have two
components, animateColor has three color components and viewBox requires
four numbers, therefore '0' itself is not directly applicable but has to be
replaced with a specific value related to the animated attribute.
According to my opinion, '0' in this paragraph is not simply the number zero,
it is just a generic symbol or a wild-card as vb is too. Therefore I
interpreted '0' always as a wild-card for the neutral element of addition in
the value space related to the animated attribute or property. Is this
correct?
-> If yes, I suggest to add something like this:
'Note, that '0' is used here as a generic symbol for the neutral element of
addition for the value type of the animated attribute or property. For example
for animateColor '0' is used here as a symbol to be replaced with black or
#000 or rgb(0,0,0), for animateMotion this is a symbol to be replaced with
the value of the origin 0,0. Similar substitutions have to be done for any
attribute value.'



---

'to animation
This describes an animation in which the animation function is defined to
start with the underlying value for the attribute, and finish with the value
specified with the to attribute. Using this form, an author can describe an
animation that will start with any current value for the attribute, and will
end up at the desired to value.

A normative definition of a to animation is given below in To animation'

-> missing a '.' at the end

-> Note that the reference still points to the informative box, not to the
normative box, this is maybe a little bit confusing within a normative
sections, because it it noted, that it references a normative definition.

'A to animation of an attribute which supports addition is a kind of mix of
additive and non-additive animation.'

-> Well, this is now indicated only as informative, this was not the case in
SMIL2.
My interpretation now is, that it is not important, if the attribute supports
addition or not, one has to follow the normative formulars below anyway?
But then the sentence above can be shortend to avoid confusion:

-> 'A to animation of an attribute is a kind of mix of additive and
non-additive animation.'

Hello SMIL working group,

some comments of minor
importance on chapter 7:


7.4.1



'a URI'

and

'a URL'


In general: URI, URL or IRI?


---------

7.5.2 and 7.5.3

'id
This attribute specifies the ID by which the param group
is referenced in a media object reference.'

'The value is a single IDREF that refers to the ID...'

-> reference or define meaning of 'ID', 'IDREF'...


--------------
7.6.2

'Example:'

- shouldn't this word be in the following box?
Else the word is indicated as normative, but the
example itself is informative ;o)

- reference or define the elements par, seq
not define or explained before ...


------------------
7.9.1


example really normative or only informative?


------------------
7.11.1

'alt may be displayed in addition to the media, or instead of
media when the user has configured the user agent to not
display the given media type.'

-> The name of the attribute and the meaning of the attribute
with the same name in (X)HTML suggests, that it is only used
alternatively, not additionally. Is it really required to deviate
from this established behaviour?

'It is strongly recommended that all media object elements have
an "alt" attribute with a brief, meaningful description. Authoring
tools should ensure that no element can be introduced into a SMIL
document without this attribute.'

'The title attribute as defined in the SMIL Structure module.
It is strongly recommended that all media object elements
have a title attribute with a brief, meaningful description.'

-> Why do most examples have no alt and title attributes on all media
objects in the draft, if the draft itself strongly recommends, that there
should be such attributes with a brief, meaningful description?
This gives the impression, that the example are either all low
quality or the authors of the example do not care about
'strongly recommended' behaviour ;o)

Having short fragmentational examples with something like
<video src="example.ogg" .../> is ok - everyone will assume,
that '...' includes alt or title, but
there are many more exhaustive examples (without '...') and without
alt or title in the draft... why if it is strongly recommended to use them?

-> example really normative or only informative?

Hello SMIL working group,

some comments on examples in chapter 16


16.6.3

example 5:

'<img src="img1.jpg" dur="2s" transOut="awipe" .>'
->
'<img src="img1.jpg" dur="2s" transOut="awipe" ... />'?


----------------

16.7.1

example:

'<foo xmlns:xlink="http://www.w3.org/1999/xlink">
...
<transitionFilter xlink:href="#foo" .../>
...
</foo>'

-> shouldn't it reference an id attribute or an xml:id attribute?
or is the name of the element the same by chance?
-> maybe better this?

'<img xmlns:xlink="http://www.w3.org/1999/xlink" id="foo" ...>
...
<transitionFilter xlink:href="#foo" .../>
...
</img>'

---------------
example:

'<video id="video1" src="car.avi">
<transitionfilter id="trans1"
type="ellipseWipe" subtype="circle"
begin="2" dur="12" calcMode="discrete"
values="0.083; 0.166; 0.250; 0.333; 0.416; 0.500;
0.583; 0.666; 0.750; 0.833; 0.916; 1.000;" />
</video>'
typo?
-> the value of the values attribute cannot end with
';'
-> missing strongly recommended alt attribute for video...

Hello SMIL working group,

some typos in chapter 19
and a comment on
'licensed media formats'




19.1

typo?

'specifcation'

-> 'specification'?

---------------

19.4.8

typo/missing whitespace:

'and brushbrush elements'

-> one brush to much?

------------

19.4.9

'The following licensed media formats are recommended to be supported:'

Is it possible to offer links/references to the license conditions for
example for ascii, utf-8, JPEG, PNG, SVG tiny etc?
This could maybe simplify the decision for implementors to care about
these formats or not ;o)
(this applies to the other profile chapters as well)

Hello SMIL working group,

some comments on chapter 6:

6.7/8


- Examples:
reference the definition of the id attribute and
of elements like seq, par, img, video, text, previously
not defined or referenced...
(bad document structure, because these features are
defined in later chapters but used and not explained here)

------------------------
6.8

- wouldn't it be useful to have a type (and a title attribute
it think it has, but the reader cannot identify this at this
point of the specification, because this is defined in chapter
10 - somehow opaque document structure)
for the a element as in (X)HTML?

------------------------

6.8.2

'The semantics of the area element in SMIL 3.0 is the same as it is for
HTML in that it can specify that a spatial portion of a visual object can
be selected to trigger the appearance of the link's destination.'

-> reference the module that defines visual objects?
I think, in HTML, area can only appear inside map, therefore
the sematics here seems to be slightly different, if there is
no map but visual objects...

---------------

'as in HTML [HTML4], the area element that is encoded earliest
in the document takes precedence.'

- I looked for this in HTML4.01, but could not find it.
Which chapter? Which section?

--------

What happens, if the used visual object is itself interactive,
for example a SVG or (X)HTML document with a elements?
Is a 'click' in an area of such an object related to its interactivity
or to the linking behaviour of the area element?

Does it only depend on the sensitivity attribute of the
MediaRenderAttributes module?
If yes - maybe useful to mention it here as an informational
note with a reference to the module...
And because the object is on top and the a is the parent, the
a will never get an event?
And because the area is inside the object, the area will always
get the event?

I think, there is a paragraph in 6.6.1 about this, but it is
neither indicated as normative nor informative, therefore I'm
not sure if this is applicable here.


--------
Examples:

If it is strongly recommended that all media object elements have an
"alt" attribute, why do especially the area elements of the example
do not have them (in HTML alt is required for area for example)?


Example 1:

'<smil xmlns="http://www.w3.org/2007/07/SMIL30/Language">
<body>
<video src="video" title="Interview" >
<area id="firstQ" begin="0s" dur="20s" title="first question" />
<area id="firstA" begin="first0.end" dur="50s" title="first answer" />
</video>
</body>
</smil>'

-> really begin="first0.end" or begin="firstQ.end" ?
first0 would be outside the example?


------------------

6.9.1

' <ref src="menu.html" region="menubar">
<area fragment="menuitem1" href="#selection1"/>
</ref>'

-> define or reference definition or ref...

Hello SMIL working group,

some comments on chapter 12:

12.3.1

typo:

'... as well as any time maniuplations defined ...'
->
'... as well as any time manipulations defined ...'

-------------

12.3.2

'It will produce a simple pendulum swing on the target
(assume that the target is a pendulum shape with the transform
origin at the top):
<animateTransform type="rotate" from="20" to="-20" dur="1s"
repeatCount="indefinite"
accelerate=".5" decelerate=".5" autoReverse="true" ... />

The pendulum swings through an arc in one second, and then back again
in a second.
....
This produces a realistic looking animation of real-world pendulum motion.'

-> Note that the motion of a (rotating, mathematical) pendulum is an
anharmonic oscillation. It is technically not easy to build a pendulum
with such a motion, therefore real-world pendulums behave different.
-> The motion related to these attributes is that of a constant force
(free fall close to the earth surface) as far as I understand this. With
this example it should be possible to produce a quadratic spline
approximation for a harmonic oscillation, because it includes
autoReverse="true", however I did not check, if the given example
really is the correct quadratic spline approximation for a sine related
to a harmomic oscillation and it is not the motion of a pendulum,
especially not for large amplitudes.
-> For (an)harmonic oscillations the autoReverse is still very useful, but the
approximation of the motion requires itself a values-animation with
calcMode spline and maybe keyTimes. Additionally the values list needs to
be calculated symmetrically around '0' to make use of the autoReverse.


-------------

Example:

"<par speed=2.0>
<animate begin="2s" dur="9s" speed="0.75" .../>
</par>"

-> speed="2.0" ?

-------------
12.3.3

wording?

'r(t) is the speed modification due to acceleration and deceleration,
at any time t within the simple duration.'

-> as far as I understand this, r(t) is the run rate itself at any time t,
not its modification, this would be dr/dt and would be called acceleration.

better:
->
'r(t) is the run rate, time dependent due to acceleration and deceleration,
at any time t within the simple duration.'

Hello SMIL working group,

this looks like a typo:

15.6.5

'This is not be be confused...'

->
'This is not to be confused...'?

Hello SMIL working group,


some comments on the SplineAnimation Module:


3.9.1 SMIL 3.0 SplineAnimation Module Attributes

'Discrete animation can be used with keyTimes, as in the following example:
<animateColor attributeName="color" dur="10s" calcMode="discrete"
values="green; yellow; red" keyTimes="0.0; 0.5; 0.8" />

The value of the "color" attribute will be set to green for 5 seconds, and
then to yellow for 3 seconds, and then will remain red for the remainder
of the element.'

--> 'the remainder of the animation'?
or 'for the last 2 seconds of the animation'? because there is no
fill="freeze" ...?

--------------------

'<par dur="30">
<animate calcMode="discrete" repeatCount="2" dur="10" fill="freeze"
accumulate="[as specified]" keyTimes="0.0; 0.5; 1.0" values="0; 1; 2"/>
</par>'

required attributeName is missing...
reference definition of par...

-------------------------

3.9.4 The spline animateMotion element

typo?

'path
....
Support includes commands to describes lines ...'

-> '... to describe lines ...'?


'When a path attribute is used, the number of values is defined to be
the number of points defined by the path, unless there are "move to"
commands within the path. A "move to" command does not define an
additional "segment" for the purposes of timing or interpolation.
A "move to" command does not count as an additional point when
dividing up the duration.'

-> Except the first M/m command, else even with the simplest
paths there are problems:
path="M 0 0L1 1"
This is the same as values="0 0;1 1",
therefore 2 values, one segment.
Formally the first M/m command is both - at the beginning and
within too, because it is not outside of the path.

-> maybe useful to mention, that control points of cubic Bezier
curves are not counted as points ...

-> maybe useful to mention, that the default calcMode paced
requires a (numeric) calculation of the distance along a path for
cubic bezier segments. (Even if the calcMode is linear, the
motion along a cubic Bezier curve segment is paced and
requires therefore the distance along the path fragment or a
related method, because the usual parametrisations of
cubic Bezier curves are not related to a paced or linear motion).

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.

Hello SMIL working group,


some comments related to the chapters
3.4 and 3.6:


3.4.1 The simple animation function f(t)


'The animation function is a function of the current position, as well
as of time:
f(t,u) = (u*(2.5s-t)/2.5s) + 10*(t/2.5s)'

-> u is undefined at this text position.
Better:
'The animation function f is a function of the current position u(t),
as well as of time
t (here given in seconds):
f(t,u(t)) = (u(t)*(2.5s-t)/2.5s) + 10*(t/2.5s)'

Alternatively it would be useful too to define often used symbols at the
top of the animation chapter.
This is done in 3.4.2, but this is too late for this section, this indicates
a bad document structure...

------------------

'The simple animation function defined by an animation element is a
function of time,
f(t), defined for times t, 0<=t<=d, where d is the simple duration of the
element.'

-> define or reference definition of 'simple duration'

------------------

'The animation effect function, F(t,u), of an animation element with
active duration AD ...'

-> define or reference definition of 'active duration'

--------------------


'3.4.2 Summary of symbols used in the semantic descriptions

This section is informative.'

-> The symbols are used in normative parts, how can this be informative?
How can the normative parts be understandable with only informative defined
symbols? ;o)

-> reference definitions of 'simple duration', 'active duration' ...

-------------------
'3.4.3 The animation sandwich model

This section is informative.'

This was not indicated as informative in SMIL2 - sure, that this is
informative?
It contains (!)important (?) information about priorities of animations.
And if it is informative, what about this in a normative part of 3.4.1:
'This is detailed in The animation sandwich model.'
If the section is only informative and not normative, it cannot contain
any information relevant for a normative part?

--------------------

'Specifically, animating an attribute defined in XML will modify the
presentation
value before it is passed through the style sheet cascade, using the XML DOM
value as its base. Animating an attribute defined in a style sheet language
will modify the presentation value passed through the remainder of the
cascade.'

-> For example the style sheet language CSS has properties and no
attributes, what about them?
Does XSL have attributes (I think, it has mainly formatting objects and
properties)? Which style sheet language defines attributes?
Better:
'Animating an attribute or property defined in a style sheet language will
modify the
presentation value passed through the remainder of the cascade.'?
or if there are no attributes in style sheet languages:
Animating a property defined in a style sheet language will modify the
presentation value passed through the remainder of the cascade.'?

-> If we take as an example a basic shape from SVG, for them presentational
XML attributes and CSS properties exist with the same meaning and the
same name, for example the property/attribute fill. If we use
attributeType XML and CSS we can distinguish between them.
This paragraph means that the animation using attributeType XML is
applied before it is passed through the style sheet cascade, while
with attributeType CSS (or auto) it is applied to the remainder of the
cascacde. Is this correct? This means animations using attributeType XML
are overwritten for example by external author style sheets, because
those are later in the style sheet cascade. But using attributeType CSS
means, the animation superseedes the style sheets again (if there is no
!important from a user style sheet). Is this correct?

------------------------------
3.4.5 The animation effect function F(t,u)


typo?

'The effect of the animation is to to just use the value for f(0), setting
the fill color to red for the remainder of the animate element's duration.'
->
'The effect of the animation is just to use the value for f(0), setting the
fill color to red for the remainder of the animate element's duration.'?


---------------------

'For example, the path notation for a simple arc (detailed in
The animateMotion element)
can be used to describe a bouncing motion:

<img ...>
<animateMotion path="m 0 0 c 30 50 70 50 100 0 z" dur="5s"
accumulate="sum" repeatCount="4" />
</img>'

-> Note that this example is in the BasicAnimation module and references
animateMotion from the BasicAnimation module but the path attribute is
from the SplineAnimation module. This might confuse a little bit and
is not very comfortable for readers, if they really want to understand
this.
-> minimal improvement would be a reference from the 'path notation' to
the related section of the SplineAnimation module and a note, that for
this example the SplineAnimation module is required...




--------------------
3.4.6 Additive animation

'An element may be defined as additive only if addition is
defined for the type of the target attribute.'

-> What happens, if this is not explicitely specified for the
target attribute? No animation at all?

-------------------

' This section is informative.

When there are multiple animations defined for a given attribute that overlap
at any moment, the two either add together or one overrides the other...'

-> Sure that this is only informative? In SMIL2 it was not indicated as
informative
and contains important (?) information on priorities and about the question,
for
which types of attributes additive animation may be defined...

-------------------

'<img top="10" ... >
<animate dur="10s" repeatDur="indefinite"

attributename="top" from="20" by="10"

additive="sum" accumulate="sum" />
</img>

The animation adds to the original value of 10 that was set for "top",
and begins at the value 30. It moves down by 10 pixels to 40, then repeats.
It is cumulative, so the second iteration starts at 60 (the value of 40 from
the previous iteration plus 20) and moves down by another 10 to 70, and
so on.'

-> better:
'... (the value of 30 from the previous iteration plus 20 from the from
attribute and plus 10 from the underlying value) ...'

This is not important in this situation, but for attributes with not
commutable addition the order of the additions is important
(for example SVG has such attributes), therefore it is important to
pronounce that 60 results from three additions with numbers from
three different sources...



------------------------

3.6.2 Specifying the simple animation function f(t)


- What is recommended for calcMode paced, if there is
a known procedure to produce an even pace of change
across the animation, but this procedure does not interpolate
between the values? This happens for example for a list
of numbers or coordinates as animated values.
Such lists are no vectors, sometimes lists of vectors.
Fallback to linear?
A SMIL3 example is the new viewBox, as already commented.

Hello SMIL working group,


some comments related to the chapter
11.4.3:

end, examples:


'<html ...>
....
<video dur="media" end="click" src="movie.mpg" .../>
....
</html>'

-> (1) This looks like a mixture of XHTML and SMIL?
XHTML does not have a video element
(ok, maybe HTML5 will have one, but
unfortunately no SMIL timing for it).
SMIL does not have a html element.
But if it is a mixture, doesn't either the
html or the video or the attributes need a
xmlns prefix?
Or another element with a xmlns attribute
for SMIL?
-> maybe better to use a smil element
instead of html to simplify the example...

----------


'<html ...>
....
<img src="image.jpg" end="click" />
....
</html>'

-> in XHTML for the img element an alt attribute is
required, even if this is combined somehow with as
as suggested here...
And maybe either the html, img elements or the
end attribute need some XMLNS prefix?
-> maybe better to use a smil element
instead of html to simplify the example...


-----------------

min, max examples:

'<html ...>
....
<par endsync="first" min="12s" fill="freeze" >
<video id="video_of_15s" end="click" ...>
<video id="video_of_10s" .../>
</par>
....
</html>'

-> see comment (1) correspondingly

'<par dur="5s" min="12s" >
<video id="video_of_15s"/>
<video id="video_of_10s" />
</par>'

-> missing '...'?
->
'<par dur="5s" min="12s" >
<video id="video_of_15s" .../>
<video id="video_of_10s" .../>
</par>'?
else the src attribute is missing ...

--------------


event value syntax

'Since the event will never be raised on the specified element,
the event-base value will never be resolved.'

-> the CSS box for this informative indicated container
covers some normative text on top and below.
-> change styling...

--------------

'<html ...>
....
<video id="foo" repeatCount="10" end="endVideo.click" ... />
<img id="endVideo" begin="foo.repeat(2)" .../>
....
</html>'

->
see comment (1) correspondingly

-----------

repeat values

typo?

'If this qualified form is used, the eventbase value will only be resolved
when a repeat is observed that has a iteration value that matches the
specified iteration.'

->
'... has an iteration value ...'?

---------------

The endsync attribute

'the child elements must complete all instances of active durations for
resolved begin times.'

and

'In the case of an element that restarts (e.g. because of multiple begin
times), the element is considered to have ended its active duration when
one active duration instance has completed. It is not a requirement that
all instances associated with multiple begin and end times complete, to
satisfy the semantics of endsync. This means that if the element is playing
a second or later instance of an active duration, it may be cut short by a
parent, once the other children satisfy the endsync semantics.'


-> define or reference definition of an 'instance'

-------------

The fill attribute:

styling inconsistency?

'This section is normative

The fill attribute allows an author to specify that an element should be
extended beyond the active duration by freezing the final state of the
element.
The fill attribute is also used to determine the behavior when the active
duration is less than the duration specified in the min attribute.
For this reason, rather than referring to the end of the active duration,
this description refers to the "last instance of the simple duration".'

--> This box has a styling of an informative text, not normative...

-------------

'For this reason, rather than referring to the end of the active duration,
this description refers to the "last instance of the simple duration".'

and

'For visual continuous media, the "frame" that corresponds to the end of the
last instance of the simple duration is shown.
For algorithmic media like animation, the value defined for the end of the
last instance of the simple duration should be used.
For time containers, freezing extends the state of all children that are
active or frozen at the end of the last instance of the time container simple
duration.
The children are frozen as they appear at the end of the last instance of the
time container simple duration. If a child element ends its active duration
coincident to the end of the last instance of its parent time container
simple duration, the child element fill value determines whether the child
will be frozen after the end of the parent time container's last simple
duration.'

and

'Freezing an element extends it, using the final state defined in the
last instance of the simple duration.'

and maybe more of this in this section

-> (2) define or reference definition of a
'last instance of the simple duration'
At this point the reader cannot understand what this means.
Is it for example the last value of a simple duration?
The current value if the active duration ends? Is it the last frame
of a video or the current frame when the simple duration is
cut short?

------------------
Resetting element state

'Any instance times associated with past event-values...'

->
see comment (2) correspondingly

----------------
The restart attribute

-> is any list entry of the begin list (except the first begin and indefinite)
related to the restart attribute?
-> for example begin="0s;20s;60s" restarts at 20s and 60s?
if yes (I think so), maybe useful to mention this simple situation
in the informative list...
-> I think, it would be useful to list or explain here exactly, when
an element restarts or to reference to a normative section, where
this is explained. It does not really help to reference an informative
section to 'define' this.

-------------

example:

'<html ...>
....
<span begin="click" end="click" timeAction="class:highlight"
restart="whenNotActive">
Click here to highlight. Click again to remove highlight.
</span>
....
</html>'

-> reference definition of 'timeAction'
-> (3) (X)HTML does not have such an attribute
(and no begin, end, restart)
maybe use xmlns prefixes to avoid confusion

------------

' restartDefault = ( "always" | "whenNotActive" | "never" | "inherit" )
Defines the default value for the restart behavior for an element.
The values "always", "whenNotActive" and "never" specify that the
element restart behavior is the respective value...'

-> '... as defined for the restart attribute.'?

------------

'syncBehaviorDefault = ( "canSlip" | "locked" | "independent" | "inherit" )
Defines the default value for the runtime synchronization behavior for an
element.
The values "canSlip", "locked" and "independent" specify that the element's
runtime
synchronization behavior is the respective value.'

-> '... as defined for the syncBehavior attribute.'?


'syncToleranceDefault = ( Clock-value | "inherit" )
Defines the default value for the runtime synchronization tolerance value
for an element. Clock values specify that the element's runtime
synchronization tolerance value is the respective value.'

-> '... as defined for the syncTolerance attribute.'?

---------------

The timeAction attribute

examples:

->
see comment (2) correspondingly if this is (X)HTML

Hello SMIL working group,


some comments related to the chapters
11.4.4 to 11.11:



11.4.4

The peers, higher, and lower attributes


'The rules for adding the element to the queue are described below.'

-> the CSS box for this informative indicated container
covers some normative text on top and below.
-> change styling...

----------------------


Calculated times and pause/defer semantics

'<html ...>
....
<excl dur="indefinite">
<priorityClass peers="defer">
<img id="foo" begin="0s" dur="10s" .../>
<img id="bar" begin="foo.click" .../>
</priorityClass>
</excl>
....
</html>'

and
Handling Simultaneous Begins within excl

<html ...>
....
<excl>
<img src="image1.jpg" begin="0s".../>
<img src="image2.jpg" begin="10s; image1.click".../>
<img src="image3.jpg" begin="20s; image2.click".../>
</excl>
....
</html>

and
Implicit duration of media element time containers

'<html ...>
....
<video src="vid1.mpg" endsync="all" >
<set dur="8s" .../>
<animate begin="click" dur="5s" .../>
</video>
....
</html>'

and

'<html ...>
....
<video src="vid1.mpg" timeContainer="seq" endsync="first" >
<animate dur="4s" .../>
<animate end="click" .../>
</video>
....
</html>'

and (in 11.4.5 Computing the active duration)

'<html ...>
....
<seq>
<img src="slide1.jpg" dur="10s" end="click" />
<img src="slide2.jpg" dur="10s" end="click" />
<img src="slide3.jpg" dur="10s" end="click" />
<!-- etc., etc. -->
</seq>
....
</html>'


-> (1)
This looks like a mixture of XHTML and SMIL?
XHTML does not have a video (excl, seq etc) element.
SMIL does not have a html element.
But if it is a mixture, doesn't either the
html or the video or the attributes need a
xmlns prefix?
Or another element with a xmlns attribute
for SMIL?
-> maybe better to use a smil element
instead of html to simplify the example...

--------------------


11.4.5


Detecting Cycles

typo?

'If there is a dependency cycle, The propagation path will...'
->
'If there is a dependency cycle, the propagation path will...'?



-----------------

Event sensitivity


<html ...>
....
<audio src="bounce.wav" begin="foo.click"
end="foo.click+3s" restart="whenNotActive"/>
....
</html>

and

<html ...>
....
<audio src="bounce.wav" begin="foo.click" dur="3s"
restart="whenNotActive"/>
....
</html>



-> html? smil?
->
see comment (1) correspondingly


-----------------

Hyperlinks and timing

'Note that the begin time may be resolved as a result of an earlier
hyperlink, DOM or event activation.'

-> the CSS box for this informative indicated container
covers some normative text on top and below.
-> change styling...


-----------------------

'<html ...>
....
<par begin="0">
<img id="A" begin="10s" .../>
<img id="B" begin="A.begin+5s" .../>
<img id="C" begin="B.click" .../>
<img id="D" begin="C.begin+5s" .../>
...
<a href="#D">Begin image D</a>
</par>
....
</html>'

-> html? smil?
->
see comment (1) correspondingly

-----------------------

Propagating changes to times

'If an element ends later than its specified end time
(e.g. if a negative offset is specified with a user event),
the propagated time must be the computed time and not
the observed time.
If an element ends earlier than its specified end time
(e.g. if a parent time container constraint cuts short the element,
or a DOM method call ends the element), the propagated time
must be the constrained time.'

-> the CSS boxes for the informative indicated containers
cover some normative text on top and below.
-> change styling...

-------------------

'<html ...>
....
<par>
<img id="img1" dur="10s" end="click" .../>
<video begin="img1.end-3s" restart="whenNotActive" .../>
</par>
....
</html>'

-> html? smil?
->
see comment (1) correspondingly

-------------------

Time container constraints on child durations

typo?

'When the par repeats the first time,
everything has happens just as it did the first time.'

-> '... everything happens ...'?

-------------------

11.5.1

'A typical example is that the document is displayed on a screen.'
and some more:
-> the CSS boxes for the informative indicated containers
cover some normative text on top and below.
-> change styling...

------------

11.5.3

'For example, host language designers may not define
error recovery semantics for missing or erroneous values
in the begin or end attribute values.'

-> the CSS box for this informative indicated container
covers some normative text on top and below.
-> change styling...


-----------------
11.7


UTC: Coordinated Universal Time

'
"Universal Time" (abbreviated UT) is sometimes also referred to
as "Greenwich Mean Time" (abbreviated GMT).
The two terms are often used loosely to refer to time kept on
the Greenwich meridian (longitude zero), five hours ahead of
Eastern Standard Time. Times given in UT are almost always given
in terms of a 24-hour clock. Thus, 14:42 is 2:42 p.m., and 21:17
is 9:17 p.m.
'

-> As far as I know, GMT is a historical outdated time format,
UT is a little bit newer but outdated too since 1968 as a pure
time standard, it would be confusing to use UT as
abbreviation for UTC ;o)
The current versions are called UTC and TAI.
UTC is roughly a weighted average of high precision atomic
clocks from several countries (TAI), adjusted sometimes to
the rotation of the earth (UT).
-> see for example wikipedia or other sources...
-> maybe refer to an informative reference for UTC

-> I searched for 'UT' in this chapter but outside this
definition paragraph I found only 'UTC', maybe useful to
replace this paragraph:

'UTC is the current atomic time standard based on TAI
(International Atomic Time) and a leap second relation to
UT (Universal Time, based on the rotation of the earth;
similar to the outdated GMT, Greenwich Mean Time).
Times given in UTC are almost always given in terms of a
24-hour clock.
Thus, 14:42 is 2:42 p.m., and 21:17 is 9:17 p.m.'


------------------
11.9.5


'<html ...>
....
<seq repeatCount="10" end="stopBtn.click">
<img src="img1.jpg" dur="2s" />
<img src="img2.jpg" dur="2s" />
<img src="img3.jpg" dur="2s" />
</seq>
....
</html>'

-> html? smil?
->
see comment (1) correspondingly



------------------
11.11.2

typo?

'... time.begin ...'

-> missing whitespace
-> '... time. begin ...'

Hello SMIL working group,

there is an inconsistency in
the behaviour of the fill attribute
in SMIL 3 (and SMIL 2).
The discussion was already started
for SMIL 2 ( for example
http://lists.w3.org/Archives/Public/www-smil/2007JanMar/0017.html
and the following)
but was not finished
yet and applies to the LC of
SMIL 3 as well.





First assume this example with a video
having only 3 frames:

[0s;1s) : red frame
[1s;2s) : green frame
[2s;3s) : blue frame

<video src="3sRGB3frames"
alt="video with 3 frames; duration 1s per frame; frames: red, green, blue"
dur="3s" begin="1s" end="3s" fill="freeze" />

.... and a related animation example:

<animate attributeName="color"
values="red;green;blue"
calcMode="discrete" fill="freeze"
dur="3s" begin="1s" end="3s" />

Presentation without an end attribute is therefore in both cases:
[1s;2s) : red
[2s;3s) : green
[3s;4s) : blue
and later blue too.


To get the correct behaviour with the end attribute
lets resume some sections:


11.4.5

The instance times lists

'offset-values are the simplest. Each offset-value condition
yields a single instance time. This time remains in the list
forever, and is unaffected by reset of the element, or by
repeat or restart of the parent (or other ascendants).'

Examples above
-> instance time list for begin: 1s
-> instance time list for end: 3s

11.4.3

Dur value semantics

'dur
Specifies the simple duration.'

Examples above
-> simple duration: 3s


The fill attribute

'For visual continuous media, the "frame" that
corresponds to the end of the last instance of the
simple duration is shown.'


-> what is the 'end of the last instance of the
simple duration'?
A duration is not directly related to a moment in time.
In the video example above the simple duration
is related to an interval [1s;4s).
Instances seem to be related to
moments, not to (time) intervals.
Therefore if an instance is only a moment
it is obscure what the end of this moment is.

The related end is at 3s. This is the last end
instance time according to 11.4.5.
But this does not answer, what the end
of the last instance of the simple duration is.
1s the begin, 3s the (exclusive) end of the
interval related to the (cut off) simple duration.

If 'last instance' nevertheless is meant to be
related to intervals (the last repetition of
the simple duration?), the 'frame'
corresponding to the end of the last
instance of the simple duration is
the green frame in the video example
above.


'For algorithmic media like animation, the value
defined for the end of the last instance of the
simple duration should be used.'

-> what is the 'value defined for the end of
the last instance of the simple duration'?

Here we have almost the same arguments
for the animate element as for the
video element. The simple duration
is related to an interval [1s;4s).
Instances seem to be related to
moments, not to (time) intervals.
Therefore if an instance is only a moment
it is obscure what the end of this moment is.

The related end is at 3s. This is the last end
instance time according to 11.4.5.
But this does not answer, what the end
of the last instance of the simple duration is.
1s the begin, 3s the (exclusive) end of the
interval related to the (cut off) simple duration.

If 'last instance' nevertheless is meant to be
related to intervals, the value
corresponding to the end of the last
instance of the simple duration is
the color green in the animate example
above.

-> This looks as a 'good' interpretation, because it fits to the
definition of the fill attribute in the
SMIL animation recommendation 04-September-2001
http://www.w3.org/TR/2001/REC-smil-animation-20010904/
3.3.5:

'freeze
The animation effect F(t) is defined to freeze the effect
value at the last value of the active duration.'

-> Because the active duration interval is inclusive begin
and exclusive end the frozen value is green.

-> Because SVG 1.0/1.1/ Tiny 1.2 use the same definition,
this is consistent with them too.

-> In SMIL 1.0 I could not find any detailed description
for the fill behaviour related to the video example.


However there is a problem with the SMIL3 section 3.4.5 ...
freezing animations.
The formulas given in this section are consistent with
this interpretation if calcMode is linear, paced or spline
(There is an exception related to animateMotion using
the path element, see below), but not always if it is
discrete.
With these formulas the frozen value of the
animation example above would result in blue and
not green.
Therefore there is a probable contradiction between
SMIL 3 Chapters 11.4.3 and 3.4.5 and there
is an obvious incompatibility between SMIL 3
Chapter 3.4.5 (respectively SMIL2) and the
SMIL animation recommendation 04-September-2001
3.3.5 and the derived definitions in SVG 1.0/1.1/ Tiny 1.2.

This causes already some confusion in SVG Tiny 1.2,
because this references already SMIL 2.1, but the
inconsistent formulas cannot be used, because they
do not fit to the its definition of fill for calcMode
discrete.

Therefore my suggestion is to do some minor changes to
the normative section for fill in SMIL 3.0, 3.4.5 and
to add an errata to SMIL 2 to fix this problem.
Unfortunately the specific rule for the case where the
active duration is a multiple integer of the simple
duration can be found already in the
SMIL animation recommendation 04-September-2001,
therefore to avoid compatibility problems, this has to
be taken into account too.

The change could be something like this:

old:
'Normative
The frozen animation function, ff(t),
for an element with active duration AD, is given by
ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen)
When the element is frozen, t is effectively equal to AD.
....' (etc)

new:
'Normative
The frozen animation function, ff(t),
for an element with active duration AD, is given by
ff(t) = fc(t) for all times t: 0<=t<AD (i.e. before it is frozen) and
ff(AD)= limes (e>0 to 0; fc(AD - e))
with the following exceptions:
If AD is an multiple integer of d, i.e. AD = d*i for some positive integer
i ,
and the animation is non-cumulative, ff(t) = f(d).
If AD is an multiple integer of d, i.e. AD = d*i for some positive integer
i ,
and the animation is cumulative, ff(t) = f(d)*i.

Informative
If the limes is elaborated, this results in the following rules.

For calcMode[reference related section] linear, paced and spline
(and no animateMotion with path fragments separated from each
other):

When the element is frozen, t is effectively equal to AD.
...' (etc)

and additionally:

'For calcMode discrete (or animateMotion with
path fragments separated from each other):
The frozen value is the last value of active
duration. Note that the active duration is related to a
time interval with inclusive begin and exclusive end.
Therefore if the end of active duration meets exactly
the time, the animation jumps to a new value, this jump
does not take place. The only exception to this is a
keyTimes value of one and the active duration
is an integer multiple of the simple duration, then the
value related to keyTimes 1 is used as a frozen value
respectively the multiple of the value for cumulative
animations as defined above.'

------------------------------------

Details about the problem with
animateMotion using paths with several M/m
commands...

To identify this we can use the following
example:


<animateMotion calcMode="paced"
path="M100 100 m100 100l100 100
m100 100l0 0
m100 100l100 100
M0 0"
dur="6s"
fill="freeze"
repeatDur="as specified" />

If repeatDur is not specified at all we get
the following motion:

time [0s;3s) motion from 200,200 to 300,300
time [3s;6s) motion from 500,500 to 600,600
frozen value at 6s and later: 0,0
(M 0 0 creates a bad or empty interval of length
zero, but defines the last value of the animation,
this is similar for calcMode paced and
path fragments like 'm100 100l0 0' or
'm 100 100z', always ignored in the animation,
if this is not the last path fragment and the
active duration is not an integer multiple of
the simple duration. However for calcMode
linear (or spline) path fragments like
'm100 100l0 0' or 'm 100 100z' take their
fraction of time, the motions stops in this
time interval).


Now we assume repeatDur="3s"

time [0s;3s) motion from 200,200 to 300,300
frozen value at 3s and later: 300,300

As we can see, this behaviour is somehow
related to a discrete animation and the
formulas in SMIL 3.0, 3.4.5 have another
problem related to the path fragments of
zero length. Because the time 3s can be
related to three values:
300,300; 400,400; 500,500

The suggested and consistent limes rule
from above avoids such problems using
simply the SMIL time interval model.


--------------------

Another minor problem with the formulas for the fill attribute
in 3.4.5:

To identify this, we can use the keyTimes 1 example from
3.9.1:

'<par dur="30">
<animate calcMode="discrete" repeatCount="2" dur="10" fill="freeze"
accumulate="[as specified]" keyTimes="0.0; 0.5; 1.0" values="0; 1; 2"/>
</par>'

Lets assume an additional min="21s".
This is the case in 11.4.3 (min/max):
'... otherwise the element is played normally for its
repeating duration (or simple duration if the element does not repeat)
and then is frozen or not shown depending on the value of the fill attribute'

Now the active duration is 21s, therefore not an integer multiple of the
simple duration 10s anymore.

But in 3.4.5 'Freezing animations'
this exotic situation is not described, because neither the
animation function at 21s nor at 20s is formally defined.
Maybe now the frozen value has to be 1 for the non cumulative case
and 3 for the cumulative case just due to the SMIL time interval
model because there is no other specific rule. Correct?
Maybe, but probably not intended.
Maybe this requires an additional note or a precision, for example
that the frozen behaviour is determined as if the active duration is
not corrected with the min attribute, if the corrected active duration
is not smaller as the uncorrected active duration.
Not nice to implement, but somehow another side effect of this
'multiple integer' rule...

Hello,

the ITS Working Group would like to make the following last call comment
on SMIL 3.0 [1] .

We would like you to adopt ITS 1.0 [2] as the preferred means for the
internationalization and localization of SMIL 3.0 documents. Concretely,
we propose the adoption of

1) an ITS "Translate" rule [3] to separate translatable and
non-translatable content,
2) an ITS "Elements Within Text" rule [4] to describe the flow
characteristics of elements, and
3) an SMIL 3.0 schema which contains ITS 1.0 markup declarations for 1)
and 2).

No 1) is important information for the localization of SMIL 3.0
documents, e.g. to make the life of translators easier. No 2) is useful
e.g. for spell checking tools.

The ITS rules file we want to propose for 1) and 2) look like this:

<its:rules
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:s="http://www.w3.org/2007/07/SMIL30/" version="1.0">
<its:translateRule selector="//s:*" translate="no"/>
<its:translateRule selector="//s:smilText | //s:div | //s:p | //s:span
| //s:@title" translate="yes"/>
<its:withinTextRule selector="//s:span" withinText="yes"/>
</its:rules>

ITS rules, see [5], are are a means to express ITS 1.0 information
independent of the target document, without a need to change your (SMIL
3.0) document. They deploy XPath for that purpose, see the "selector"
attributes. The rules are contained in an <its:rules> wrapper element.

The first two rules are used to separate translatable and
non-translatable content. They can be read as: the default for elements
is that they are not translatable (first <translateRule> element). The
exceptions (translatable elements and attribute content) are handled by
the second <translateRule> element, which takes precedence over the
first one. We assume that the translatable elements and attributes in a
SMIL 3.0 file are: smilText element [6], div element [7], p element [8],
span element [9] and title attribute [10]. It would be great to get your
feedback on this list.

The third rule about "Elements within Text" describes that the <span>
element appears in the flow of other elements, like <smilText>, <p> or
<div>. The default for "Elements Within Text" is that elements are not
nested.

About no. 3): we propose that SMIL 3.0 provides a schema which contains
the ITS markup declarations [11]. These markup declarations allow for
specifying a lot of more information related to internationalization and
localization, like localization notes [12] or terminology information
[13]. Possibly, you would not need all markup declarations available at
[11]. We would be very willing to adapt the existing ITS markup
declarations to your specific needs, if you agree on the general proposal.

Note that we don't propose that a conformant SMIL 3.0 implementation
needs to process 1), 2) or 3). Nevertheless, their availability would be
very valuable for internationalization and localization related tasks,
and the world-wide adoption of SMIL 3.0

We are looking forward for you feedback. Thank you,

Felix

[1] http://www.w3.org/TR/2007/WD-SMIL3-20070713/
[2] http://www.w3.org/TR/2007/REC-its-20070403/
[3]
http://www.w3.org/TR/2007/REC-its-20070403/#translatability-implementation
[4] http://www.w3.org/TR/2007/REC-its-20070403/#within-text-implementation
[5] http://www.w3.org/TR/2007/REC-its-20070403/#selection-global
[6] http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-smilText
[7] http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textDiv
[8] http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textP
[9] http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-span
[10]
http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-structure.html#adef-title
[11] http://www.w3.org/TR/2007/REC-its-20070403/#its-schemas
[12] http://www.w3.org/TR/2007/REC-its-20070403/#locNote-datacat
[13] http://www.w3.org/TR/2007/REC-its-20070403/#terminology

Dear Working Group Members,

I am currently having problems creating what I feel should be an easy
SMIL. I need control of some basic parameters at the start of a SMIL
file and some for the linking of files.

Here is what I am trying to do:
I have a series of video lectures that we are trying to reference for
a course. Ideally we want to show a small piece of the full lecture
but in context of the full lecture. This way a student can watch the
snippet and if they are interested, the can either drag the playback
head to just before the piece for more context or click on one of the
hyperlinks in the index and jump to that topic.

The problem:
I can get close to the desired behavior by first linking to a SMIL
file with a video with a beginClip and an endClip. But the problem is
that I don't have the full clip there so a person can't see the
context without first clicking a hyperlink to a SMIL file with the
full version of the video with a complete index, and then clicking on
a hyperlink.

Here's what I think I need:
The ability to seek to a specific time- either as a Linking attribute
(6.7 of the spec) or as part of the Media Objects as an initial
attribute (7.x.x ??). Sort of a bookmark feature (or named anchor in
HTML). Basically on clicking of a link go to this file and advance to
a specific time while maintaining the full length of the file (unlike
clipBegin, clipEnd which clips the file), e.g.

<a href="7.013-S06-VL19-0317-0729.smil" seek/advance/goto/
bookmark="30s"> Overview</a>

and/or

<video src="ocw-7.013-24mar2006-220k.rm" region="video" seek/advance/
goto/bookmark="3:07" />

*** The key is that it is only activated once. This way a person can
interact with the full video clip at anytime after the video/media
object seeks to a particular time.

The extra credit version would be to make a seekBegin and seekEnd
attribute, which would play set time while displaying the full time
line. Also, the seekBegin and seekEnd would be deactivated if the
video's current playing time was outside the range specified. The
problem with this is that I'm not sure what should happen after the
seekEnd time is reached. I don't believe it is possible to pause a
content region??If you can think of the appropriate behavior, by all
means feel free to spec it.

I am welcome to hear any feedback. Who knows- maybe it can already be
done this way and I don't know what I'm talking about.


Best regards,
Jason Player
____________________________
Jason Player
Web Production Specialist
MIT OpenCourseWare
One Broadway, 8th Floor
Cambridge, MA 02139
P 617-324-6044
F 617-253-2115
jcplayer@mit.edu
http://ocw.mit.edu/

a) SMIL integration:

1.1 We think the biggest question about SMIL 3.0 LCWD [1] for MMIWG is
"how SMIL works with MMI Architecture [2] and SCXML [3]". So we
concentrated on the interface and functionality related to the
architecture.

1.2 Maybe we (=SYMM-WG and MMI-WG) should hold some discussion about
the requirements on the interfaces. One possibility might be coming
Tech Plenary in November.

2.2 How speech/pen input could work with SMIL in interactive
applications?

2.3 How SMIL cooperate with other flow control languages e.g.
SCXML [3] ?

e.g.
Can SCXML invoke a "SMIL modality" to present information from the
user? And/or can SMIL invoke SCXML to provide user interaction
(as opposed to only rendering to the user)?

Please see also the comment 5.4 below.

2.4 Can we use SMIL more than once in a specific application?

e.g.
Can we use SMIL for (1) a talking head module which synchronize
speech synthesis and lip movement synthesis and (2) the main
server which control the syncronization with HTML based GUI etc.

2.6 How SMIL handle information which needs security e.g. credit card
numbers?

Regarding "15.7 The SMIL StateSubmission Module"
-------------------------------------------------

5.4 What kind of data and event exchanges should be considered in
practical SMIL ready multimodal applications?

e.g.
How SMIL and SCXML [3] relate to each other? Can SCXML invoke a
"SMIL modality" to present information from the user? Can SMIL
invoke SCXML to provide user interaction (as opposed to only
rendering to the user)?

b) Editorial comments:

2.1 We're afraid SMIL 3.0 specification is very big, and would like to
suggest the SYMM group provide a primer document like "XHTML+SMIL
Profile" [4] which mainly describes how to integrate SMIL modules
and other specs e.g. HTML and SVG so that authors can generate
SMIL ready Web applications easily.

The document should include:
- 1.4.2 Profiles affected by SMIL 3.0
- 22.5 SMIL 3.0 Document Scalability Guidelines
- etc.

Regarding "11.4.3 Attributes"

Style:
3.1 Following text bothers other text around it. So the style should
be modified:
[[
Since the event will never be raised on the specified element, the
event-base value will never be resolved.
]]

4. Comments on "11.6 Document object model support"

Typo:
4.1 Maybe something is wrong in following sections:
[[
11.6.6 Java language binding
11.6.7 org/w3c/dom/smil/ElementTimeControl.java:
11.6.8 org/w3c/dom/smil/TimeEvent.java:
]]

- The content of 11.6.6 is empty. Maybe 11.6.7 should be 11.6.6.1 and
11.6.8 should be 11.6.6.2 ?

- The titles of 11.6.7 and 11.6.8 should be rather "org.w3c.dom.smil/..."?


5. Comments on "15. SMIL 3.0 State"

Regarding "15.2 Introduction"
------------------------------

Typo:
5.1 "etc" in "higher priority node has preempted them, etc" should be
"etc." (missing "." at the end of the sentence).

Regarding "15.6.4 Examples"
----------------------------

5.2 Is this example really the one for "15.6 The SMIL UserState Module"?
It seems a bit strange because it says "Here is a SMIL 3.0 Language
Profile example" but doesn't mention <state> element at all.

Regarding "15.6.6 Data Model Events"
-------------------------------------

5.3 "contentControlChange(attrname)" event and "contentControlChange"
event should be also raised by each state, considering the
possibility of substate or Russian-doll usage of SMIL.

Regarding "15.7.4 Examples"
----------------------------

5.5 The examples for this StateSubmission Module must be added ASAP,
because I can't imagine how to use <submission> element or <send>
element without the examples.

----------------------------------------------
6. Comment on "17. SMIL 3.0 Language Profile"
----------------------------------------------

Regarding "17.4.13 Timing and Synchronization Modules"
-------------------------------------------------------

6.1 "Supported Event Symbols" should be links to their detailed
description.

--------------------------------------------
7. Comments on "20. SMIL 3.0 DAISY Profile"
--------------------------------------------

Regarding "20.4.7 Media Object Modules"
----------------------------------------

7.1 There is some simple description of <param> element for TTS
(=speech output) here, however, no description on ASR (=speech
input). What should we do to integrate speech recognition
(=speech input)?

e.g. (of TTS)
<param name="daisy:use-renderer" value="tts"/>
<param name="daisy:renderer-parameters" value="voice=joe"/>

Regarding "20.4.13 Playback Guidelines"
----------------------------------------

Typo:
7.2 The link to "UAAG checkpoint 2.4" should be
not "http://www.w3.org/tr/UAAG10/guidelines.html#tech-time-independent"
but "http://www.w3.org/TR/UAAG10/guidelines.html#tech-time-independent"
^^
("TR" should be capital letters)

------------------------------------------
8. Comment on "21. SMIL 3.0 Tiny Profile"
------------------------------------------

Regarding "21.3 SMIL 3.0 Tiny Profile"
---------------------------------------

8.1 M3U, PLP, PLS and WPL should be described by <acronym>

------------------------------------------
9. Comment on "Appendix A. SMIL 3.0 DTDs"
------------------------------------------

Typo:
9.1 All the headings have duplicated section number e.g. "A.1 A.1".


-------------------------------------------------
10. Comments on "Appendix E. SMIL 3.0 Reference"
-------------------------------------------------

Typo:
10.1 The title of this page is "SMIL 2.1 References" which should be
"SMIL 3.0 References".

10.2 There is an extra ">" (&gt;) right before the <h1> heading.

c) Answered in another place:

2.5 Is an IRI acceptable for a URI?

=> Please see resolution at LC-1825, and CC response to Kazuyuki Ashimura <ashimura@w3.org>.

8.3 SMIL 3.0 BasicText Module


8.3.1 Elements and Attributes

....

The elements defined in this module are:

smilText
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-smilText>
tev
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textTev>
clear
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textClear>
br <http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-br>

The attributes defined in this module are:

begin
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textBegin>
next
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textNext>

....


The tev Element

The tev
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textTev>
element defines a "temporal moment" within a block of smilText content.
Depending on the values of the begin
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textBegin>
or next
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textNext>
attributes, it determines a scheduling time at which the associated text
content (up to the following tev
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textTev>
or clear
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textClear>
element or the end of the smilText
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-smilText>
element) is rendered. This element does not define a content container,
but is simply a temporal marker within a text fragment.


______________________________________________________________
Comment:

It is unclear what should happen when in a tev
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textTev>
element
both begin
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textBegin>
and next
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#adef-textNext>
attributes are present, none of these
are present, or multiple of these are present.
Same for clear
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textClear>
element.


______________________________________________________________


....


The begin Attribute

This attribute defines an absolute time, relative to the beginning
of the parent smilText
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-smilText>
element, when the associated tev
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textTev>
or clear
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html#edef-textClear>
element becomes active.
The attribute value is a semi-colon separated list of begin-values:

begin-value : ( clock-value | event-value )
Defines the element's begin time.
Clock-value
<http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-timing.html#Timing-ClockValueSyntax>
Describes the element begin as a non-negative offset from the
start of the element's smilText container. The offset is
measured in parent simple time.
...


The general semantics of this element are the same as the SMIL begin
attribute defined within the timing module, with the restriction
that only a subset of potential time values are supported.


______________________________________________________________
Comment:

It is unclear which subset of potential time values is referred to.


______________________________________________________________

Dear Group,



I hope I do not ask any old well-known question...

Was it intentional not to refer to RFC2119 when specifying the required
and recommended features in the SMIL3.0 specification?


I have reviewed a few chapters and there are statements like "are
required to be supported" or "is recommended to be supported".

RFC2119 terms are however used in XML, XHTML etc specs that referred to
in SMIL3.0.

Thanks.

[this is not an official comment from the I18N Core WG,
but I hope it becomes one]

At 05:17 07/08/31, ishida@w3.org wrote:

>Comment 10
>At http://www.w3.org/International/reviews/0708-smil30/

SMIL 3.0 uses URIs in many places. These should all be replaced
with IRIs (RFC 3987), to make sure that resources containing non-ASCII
characters in their identifiers are correctly processed.

[The implementation effort for this is minimal assuming
an implementation is based on Unicode, which it has to
be anyway because SMIL is XML.]

Regards, Martin.




#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

[[
This section is normative.

For the purpose of identifying the version and the language profile
used, SMIL host language conformant documents must satisfy the following
requirements:
[...]
In case the SMIL host language conformant language profile has been
issued as a W3C Recommendation, the default namespace identifier must
satisfy the following requirements:
1. The URI is constructed conformant to the requirements set forth
by the W3C [W3C-NSURI].
]]

It seems awkward for a W3C Recommendation to normatively enforce and
reference the namespaces policy of W3C:

1. the namespace policy is a moving target. Are you expected
implementations to test the identifiers with regards to that policy?

2. the namespace policy is already enforced any way for W3C
Recommendation, so I'm not sure what it brings here except unnecessary
text in the document.

I'd rather leave it to W3C to manage their web space as they want.

Proposal: I would remove "The URI is constructed conformant to the
requirements set forth by the W3C [W3C-NSURI]."



[1] http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 3
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment: The textAlign attribute defines a number of values (start, end, left, right, center) that assume left-to-right text progression. While 'left' and 'right' seem obvious, start and end should depend on text direction (which can be set by textDirection).

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 4
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment:The default colors for both textColor and textBackgroundColor is "transparent". Is this intentional?

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 5
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment:textFontFamily doesn't define specific font names, only virtual fonts, which seems limiting.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 6
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
8 [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-text.html]

Comment:textMode append: some languages do not uses spaces between words, while others do. We assume that append does not imply a space automatically being appended. Please state this in the text.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 8
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
4.3.2 systemLanguage [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-content.html#adef-systemLanguage]

Comment:"systemLanguage" is defined in terms of RFC 1766, which has been obsolete for quite awhile. This section should say that language tags are defined in
BCP47 [http://www.rfc-editor.org/rfc/bcp/bcp47.txt]
("Best Common Practice 47"). There should be a normative reference to BCP47 following the pattern at
http://www.w3.org/TR/2007/REC-its-20070403/#bcp47 [http://www.w3.org/TR/2007/REC-its-20070403/#bcp47]
.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 9
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: S
Owner: AP

Location in reviewed document:
4.3.2 systemLanguage [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-content.html#adef-systemLanguage]

Comment:The "systemLanguage" element's matching algorithm doesn't deal with case sensitivity properly. It should refer to RFC 4647 Basic Filtering.

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-SMIL3-20070713/

Comment 10
At http://www.w3.org/International/reviews/0708-smil30/
Editorial/substantive: E
Owner: AP

Location in reviewed document:
4.3.2 systemLanguage [http://www.w3.org/TR/2007/WD-SMIL3-20070713/smil-content.html#adef-systemLanguage]
matching example for systemLanguage

Comment:In the switch element, the example for systemLanguage doesn't mention matching, only exact tag matching.Probably good to remind folks here. Other following examples also only use simple language tags. We'd suggest using a Simplified Chinese (zh-Hans)vs. Traditional Chinese (zh-Hant) example.

Thanks Daniel but I was thinking of something totally different. Let's say I have 2 movies, one for the content and one is the advertisement. Somewhere in the middle of content movie I "insert" the advertisement movie (most probably using an excl node) and while this ad is playing I want that the player to display the position of the content movie in it's seekbar (just ignoring that there is another video playing). I just don't understand how this seekbar could be synchronized with videos.

Daniel Weck <daniel.weck@gmail.com> wrote: Hi !

You can certainly skip content using SMIL.

Let's assume the advert is a 5mn clip encoded within the video file,
say between 5mn and 10mn. The goal is to play the video between 0 and
5mn, then again immediately between 10mn and the end of the video:






Hope that helps, Dan/

On 21 Sep 2007, at 16:07, Spiral Universe wrote:
> Hi,
>
> I'm doing a research on SMIL and there is a first question that
> it's on my mind and I couldn't find a concrete answer. As I
> understand SMIL document have a timeline concept, just like a video
> (can play, pause, seek, etc). But what about nodes that I don't
> want to be included in the timeline? Suppose there is a midroll
> advertisement inserted into a video that I don't want to be visible
> for the user? Should this be resolved with the SMIL player
> implementation or does SMIL already support stuff like this ?
>
> Regards,
> Mihaly Balogh
>




---------------------------------
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.