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.