W3C

List of comments on “SMIL Timesheets 1.0” (dated 10 January 2008)

Quick access to

There are 28 comments (sorted by their types, and the section they are about).

1-20 21-28

substantive comments

Comment LC-1947: Theora and SVG:
Commenter: <jose@multimedia4everyone.com> (archived message)
Context: in
A small and simple specification is good, better chance to have the whole language implemented.

Opera has a preview of the next gen browser with native Theora and SVG:

http://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/

First time I saw this, I was impressed, all that was missing was Vorbis audio and SMIL Timesheets.
Timesheets should be able to make fade in and out transitions by animating volume and opacity values on the audio/visual media.

With fade transitions, it's possible to make presentations presentable, the other feature could be added later.

The important thing is that the W3C provide an option for multimedia content other than the prevailing proprietary ones.

SMIL Timesheets, SVG, Theora, Vorbis in a Web browser is a winning combo IMHO :)


Jose Ramirez


Free your Media
'Xiph it'
at xiph.org
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1932: [Timesheets LC comment] 3.1 Timing and Synchronization
Commenter: Doug Schepers <schepers@w3.org> (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.

"Host document's elements are set to "active" and "inactive" following
the semantics of the defined time containers."

Of which defined time containers? In the host language? Please
elaborate, and include links to where the behavior is defined, or
clarify that it's the host language that defines the behavior.

---

"The base time, or the syncbase of a timesheet element is the moment
when the element is started by its parent."

We suggest replacing "when the element is started" with "when it is
started".

Started by its parent, does that mean "started by its parents time
container"? If so, say so.

---

"Starting an element does not necessarily make the referenced media
element visible. Rather, it sets the time moment "0s", to which the
element's attributes are compared."

This sounds like an informative note, please make it so.

---

"The duration of an element is primarily defined by the dur attribute."

This section is normative, and We would expect the behavior of dur to be
either fully defined here or the section to be made informative.


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1920: Only a few post-deadline questions ...
Commenter: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> on behalf of Dr. Olaf Hoffmann (archived message)
Context: Document as a whole
Hello SYMM Working Group,

just a few post-deadline questions, I'd like to ask:


1) If several external, internal timesheets are provided and
the document contains for example some SMIL animation inside
(like SVG) - how are the priorities? Similar to CSS priority
rules/specifities? Priority by timing or in case of collisions
the order in the source code of the host document?

2) I think, for details about the interaction with CSS for
example something like the SMIL animation sandwich model
is applicable as usual?

3) What about adopting animateTransform from SVG?
Because many 'designers' seem to like to rotate, to distort
content for decorative purposes, this might be a useful
feature especially for timesheets to cover more of the
stuff people might be interested in.
I think, there were already some efforts from
apple to integrate such feature into CSS, could be
better covered by SMIL/SYMM of course...

4) Why no path-animation for animateMotion
(SplineAnimation Module)? and could be useful to
adopt keyPoints from SVG ...
With only values-animation there are no really
smooth paths available and some 'designer'
might prefer the soft trajectories more than
the hard edges of values-animations.

5) Because animate anyway animates any property or attribute,
is animateColor really required for timesheets - if yes, why?

6) Now something like
'<link href="timesheet.smil" rel="timesheet" type="application/smil+xml">'
is allowed in the current draft for non-XML. This is pretty nice.
Why not to add something like this for XML:
<?xml-stylesheet href="timesheet.smil" type="application/smil+xml"
title="timed styling" alternate="yes" ?>

In both cases it is already defined by the type attribute, what the
user-agent has to expect, therefore I cannot see a specific problem
with this variant for XML and it avoids confusing messages from validators
without the ability to validate multiple namespaces in one document.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1923: [Timesheets LC comment] bravo user control
Commenter: Al Gilman <Alfred.S.Gilman@IEEE.org> (archived message)
Context: in
<note
class="inTransmittal">

The following is a consensus comment on the SMIL Timesheets
Last Call from PFWG.

Al
/chair, PFWG
http://www.w3.org/WAI/PF
</note>

The Protocols & Formats group, having reviewed SMIL Timesheets, has the
following comments for the SYMM WG:

1. The PFWG believes the timesheet model to be an extremely elegant
engineering solution, as it allows for user control over timing (pause,
stop, replay, rewind, fast forward, slow rate of play, accelerate
rate of
play, etc.) through a user timesheet. Thus a user can
exercise control over the author-defined timing. The UA or an assistive
plugin wizard can help the user to manage the timing settings.

2. SMIL Timesheets provides a mechanism for timing control. This
mechanism allows for user adjustment of the timing. This adjustment
is an
important requirement for access to interaction by People With
Disabilities. Therefore, the PFWG would like the HCG to foster the
reuse of the mechanism in SMIL Timesheets, or -- at the very least --
ensure that the personalization capabilities are not lost as other
formats implement timing control.

3. The PFWG also recommends and supports the adoption of the SMIL
Timesheet model in XHTML2, XHTML 1.1, and XHTML Modularizations.

In sum, the PFWG is intrigued and interested in the accessibility and
user-control aspects of timesheets. Because of this, and the importance
to the user-experience over control of timing cues and rates, the PFWG
approves of the timesheets model and shall follow the development of
SMIL
Timesheets closely and with great interest, and anticipates cooperating
with the editors and working group in order to ensure that the
accessibility and user-control offered by the SMIL Timesheets model is
realized.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1933: [Timesheets LC comment] 3.3 Event Model
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


"The begin, dur, and end attributes can contain references to DOM events
[DOM2Events]."

This limits the usefulness of timesheets. Host languages should be
allowed to extend the set of allowed events.

---

"The events specified are beginEvent event, which is dispatched when an
element starts and endEvent event, which is dispatched when an element
stops."

Why is there no repeatEvent?

---

"When specified by the begin attribute, an inactive or started but not
yet activated element will be activated when it receives the specified
event. The parent time containers and item elements have to be active,
though."

We don't understand this. Please clarify.

---

"When the element is specified to stop according to an event, the
element informs its parent that it has stopped and parent then decides
what should happen next. Of course, some other element could be waiting
to beactivated according to the endEvent event from the particular element."

Why is this normative, and why is there no example? Define what "not
supported" means. What is the behavior if an unsupported value is used
(this question should be answered everywhere the statement"not
supported" is used?

---

Define how timesheets interoperate with script and the DOM.


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1943: [SMIL30 CR comment] to-animation (12.6.4)
Commenter: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> (archived message)
Context: in
Hello,

just to avoid any misunderstanding and to be sure, that my
interpretation is correct about:

http://www.w3.org/TR/SMIL3/smil-animation.html#animationNS-ToAnimation

This defines a behaviour for discrete to-animations and 'otherwise'
to-animations.
Therefore 'otherwise' is applicable for calcMode linear, paced and spline,
is this correct?

If yes, I think, compared to SMIL2 and the old SMIL animation recommendation
from 04-September-2001, to-animations are pretty good covered now ;o)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1944: CSS properties
Commenter: Bert Bos <bert@w3.org> on behalf of CSS WG (archived message)
Context: in
Hello SYMM WG,

Here are the comments from the CSS WG on
http://www.w3.org/TR/2008/WD-timesheets-20080110/

In fact, there is only one comment:

It doesn't seem possible to understand how CSS properties are animated
from this draft alone. One probably has to read SMIL3 (even though it is
not mentioned as normative).



Bert
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1934: [Timesheets LC comment] 3.2 Selection Mechanism
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


"The item can reference a media element in the host language or a set of
elements by the element's tag, id or class."

In SVG you might want to point out several <rect> elements for example,
they are not defined to be media elements. Please come up with another
term that can be defined by the host language.

Replace "element's tag" with "element's localName". However, these are
all just examples of what selectors can select, and this should be
clearly stated in the text, for example:
"The item can reference a media element in the host language, or a set
of elements using a CSS selector; this makes it possible to reference
elements based, for example, on the element's localName, id, or class."

"The CSS selector can match more than one element in the document host
language, for example, when CSS class selector is used. When multiple
matching occur, a sequence of elements that all match exactly the item
element is constructed. This sequence is ordered following the host
document's order and the selection mechanism will consider the elements
as ordered in such list."

What if the order changes as the result of DOM changes? What would
happen? Is the selected ordered list static or "live"? In the "host
document's order", under which circumstances is this different from
document order (depth-first pre-order traversal)? We suggest borrowing
some wording from, or normatively referencing parts of, the Selectors
API spec, http://www.w3.org/TR/selectors-api.


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1922: SMIL Timesheets 1.0
Commenter: Marghanita da Cruz <marghanita@ramin.com.au> (archived message)
Context: in
As requested, see below.

Also, just in case, you haven't considered the convergence issues with
broadcasting,
it might be useful to check that SMIL timesheets harmonise with at least one of
the Teletext formats for DVB and the text in DAB. Other areas might be
Scheduling information and advertising breaks stuff.

Marghanita

Thierry Michel wrote:
<snip>
> Could you please resent your comment to the , as this is
> the proper mailing list for SMIL Timesheets 1.0 Last Call comments.
> We are tracking comments on this list.
<snip>

da Cruz wrote:
>> Hi Thiery,
>>
>> Perhaps editing and moving the bits you have highlighted, higher up in
>> the Introduction and into the Abstract would be useful. To me, it
>> seems more important than the reference to XML.
>>
>>>> SMIL Timesheets can be seen as a temporal counterpart of CSS.
>>>> Whereas CSS defines the spatial layout of the document and
>>>> formatting of the elements,SMIL Timesheets specify which elements
>>>> are active at a certain moment and what their temporal scope is
>>>> within a document. And as with CSS, SMIL Timesheets can be reused in
>>>> multiple documents, which can provide a common temporal framework
>>>> for multimedia presentations with different contents but identical
>>>> storylines.
>>
>> My suggested rewording would be along the lines of
>>
>> "SMIL Timesheets provide a temporaral counterpart to CSS for the
>> presentation/viewing/incorporation of Multimedia elements into
>> Webpages. SMIL Timesheets [allow an author to] specify which elements
>> are active.
>>
>> As with CSS, SMIL timesheets can be reused/are available to multiple
>> documents. "
>>
>> I don't quite understand what you are trying to say here.
>>
>> >>The document can be shown
>> >> in a user agent even if SMIL Timesheets are not supported, since the
>> >> contents and the layout are still governed by the document itself. Of
>> >> course, the temporal aspect of the document is then lost, since
>> all the
>> >> elements are active all the time."
>>
>> Perhaps....
>> "In the event SMIL timesheets are not supported by a User Agent, the
>> contents and layout, are still governed by the document, though the
>> temporal aspects of the multimedia elements may be lost."
>>
>> Marghanita
>>
>> Thierry Michel wrote:
>>>
>>> Marghanita,
>>>
>>> Thanks for your comment.
>>>
>>>
>>> I read in SMIL Timesheets 1.0 introduction the following statement
>>>
>>> "This document defines an XMLdefines an XML-based timing language
>>> that makes SMIL 3.0 element and attribute timing control available to
>>> a wide range of other XML-based languages. This language allows SMIL
>>> timing to be integrated into a wide variety of a-temporal languages,
>>> even when several such languages are combined in a compound document.
>>> Because of its similarity with external style and positioning
>>> descriptions in the Cascading Style Sheet (CSS) language, this
>>> functionality has been termed SMIL Timesheets.
>>> SMIL Timesheets can be seen as a temporal counterpart of CSS. Whereas
>>> CSS defines the spatial layout of the document and formatting of the
>>> elements,SMIL Timesheets specify which elements are active at a
>>> certain moment and what their temporal scope is within a document.
>>> And as with CSS, SMIL Timesheets can be reused in multiple documents,
>>> which can provide a common temporal framework for multimedia
>>> presentations with different contents but identical storylines. The
>>> document can be shown in a user agent even if SMIL Timesheets are not
>>> supported, since the contents and the layout are still governed by
>>> the document itself. Of course, the temporal aspect of the document
>>> is then lost, since all the elements are active all the time."
>>>
>>>
>>> Could you please say what else should we say to explain positioning
>>> of SMIL Timesheets and what it offers ?
>>> What do you find unclear ?
>>>
>>>
>>>
>>> There is also an example showing how to combine SMIL Timesheets with
>>> XHTML, for a simple slide show. This is just one example showing how
>>> to add timing with SMIL Timesheets to an XML-based languages, like
>>> XHTML.
>>>
>>> Should we have another example with another ML-based language ?
>>>
>>> Thanks for your suggestion.
>>>
>>> Thierry.
>>>
>>>
>>>
>>>
>>>
>>> da Cruz wrote:
>>>> Hi Thierry,
>>>>
>>>> As someone who has dabbled in Video on the Web and SMIL, reading
>>>> through the
>>>> abstract and introduction I found it difficult to position the
>>>> timesheets.
>>>>
>>>> It would help, those outside the SMIL group, to position the SMIL
>>>> timesheets if
>>>> the abstract and introduction provided an elaboration of what SMIL
>>>> is/offers.
>>>>
>>>> Perhaps and Audience section would also help.
>>>>
>>>> Marghanita
>>>>
>>>> Thierry Michel wrote:
>>>>>
>>>>>
>>>>>
>>>>> The Last Call review period for SMIL Timesheets 1.0 extends until
>>>>> 15 Febuary 2008.
>>>>>
>>>>> We have not yet received your comments on the public mailing
>>>>> www-smil@w3.org,
>>>>>
>>>>> In particular, comments from the following groups:
>>>>>
>>>>> - Compound Documents Format Working Group
>>>>> - CSS Working Group
>>>>> - HTML Working Group
>>>>> - Scalable Vector Graphics Working Group
>>>>> - Members of the Hypertext Coordination Group
>>>>>
>>>>> When do you plan to send your review ?
>>>>> Let us know if you need more delay.
>>>>>
>>>>>
>>>>> Thierry.
>>>>>
>>>>>
>>>>>
>>>>> Thierry Michel wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> The SYMM Working Group has published its First and Last Call Working
>>>>>> Draft of the SMIL Timesheets 1.0
>>>>>> http://www.w3.org/TR/2008/WD-timesheets-20080110/
>>>>>>
>>>>>> This document defines an XML timing language that makes SMIL 3.0
>>>>>> element
>>>>>> and attribute timing control available to a wide range of other XML
>>>>>> languages. This language allows SMIL timing to be integrated into
>>>>>> a wide
>>>>>> variety of a-temporal languages, even when several such languages are
>>>>>> combined in a compound document. Because of its similarity with
>>>>>> external
>>>>>> style and positioning descriptions in the Cascading Style Sheet (CSS)
>>>>>> language, this functionality has been termed SMIL Timesheets.
>>>>>>
>>>>>> The SYMM WG actively requests members of related WG's to read and
>>>>>> comment on these technologies.
>>>>>>
>>>>>> The Last Call review period for this document extends until 15
>>>>>> Febuary
>>>>>> 2008. Please send comments to the public mailing www-smil@w3.org,
>>>>>> including the prefix'[Timesheets LC comment]' in the subject line.
>>>>>>
>>>>>>
>>>>>> In particular, we invite comments from the following groups:
>>>>>>
>>>>>> - Compound Documents Format Working Group
>>>>>> - CSS Working Group
>>>>>> - HTML Working Group
>>>>>> - Scalable Vector Graphics Working Group
>>>>>> - Members of the Hypertext Coordination Group
>>>>>>
>>>>>>
>>>>>> Patent disclosure page of this SYMM WG is at
>>>>>> http://www.w3.org/2004/01/pp-impl/35663/status
>>>>>>
>>>>>> The SYMM WG approval for Last Call publication is at
>>>>>> http://lists.w3.org/Archives/Member/symm/2008Jan/0021.html
>>>>>> There is no formal objection associated with this document.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Thierry Michel Team contact, on behalf of the co-Chairs, SYMM
>>>>>> Working Group
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1924: [Timesheets LC comment] General Comments
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

The SVG WG has reviewed SMIL Timesheets 1.0, W3C Working Draft 10
January 2008, http://www.w3.org/TR/2008/WD-timesheets-20080110/ .

We are very interested in SMIL Timesheets, and are pleased by the
functionality that this specification provides. We believe that this
has a lot of potential in a set of well-defined and common use cases,
specifically photo galleries and slideshows, which are increasingly
being presented on the Web; the functionality this specification
provides will make it much easier to author such content.

While we are sympathetic to moving forward quickly to meet market needs,
and support the approach that this technology lays out, however, we
don't believe this specification itself is in a state suitable for
Candidate Recommendation. Most obvious are the large sections stricken
through, and there are numerous areas where the normative requirements
are not clear, and several grammatical errors. We feel that once these
matters are cleared up, though, the specification will be very useful.

It does seem mostly focused on XHTML, in general; SVG can be used for
the same use cases, so we would like you to please include SVG examples
similar to the HTML ones.

Finally, while we understand that this is a simplified subset of SMIL
functionality meant to be immediately implemented in browsers with a
solid market case, we are concerned that it may in places be too simple
for what will be desired, particularly in the areas of transitions and
navigation, and encourage you to lay the groundwork for future extensions.

We have several specific comments and suggestions to follow. To make it
easier for you to address our comments, we have split them into
individual emails by types or sections.

Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1935: [Timesheets LC comment] Index Function
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


3.4 Index Functionality
-----------------------

"Thus, the index() function becomes a shortcut to each of the
elementscomposing the ordered list and provide index numbers for the
DOMActivateevent references in the Timesheets."

The 'index()' function is not well defined. A good definition would
clearly list the allowed syntax, and say what it returns instead of
trying to define it by example. It should say if the first item in the
list has index 0 or 1 for example.

Again, the order of the selected elements list should be clearly defined
(either in this spec or by reference to another spec). It can be
expected that users want to add elements dynamically using DOM, and that
a timesheet continues to work as expected in such cases.

---

There is no example of using the 'index()' function with both
parameters, and the use cases for the second parameter are slightly unclear.

---


4.2 The item element
--------------------
"It can reference a media element or a set of elements by the element's
tag, id or class; the syntax and processing is the same to the
CSSselector [CSS2] syntax."

The comments on section 3.2 applies here too. BTW, why is the item
element defined twice? Consider making section 3.2 informative.

Also it sounds like <item> can only work on "media elements". That would
limit the use-cases in SVG. Please make that a MAY or informative statement.

---

"The select attribute links the timesheet to the document. Its value is
a comma-separated list of CSS selectors [CSS2]."

This makes it sound like a way to create a link between the documents
(like a <link> element). It might be better worded, "The select
attribute associates (or applies, or ties, or binds) the Timesheets
element to one or more node in the target document."

Please consult the CSS WG if you haven't already done so, to make sure
that comma is the best list-separator character for selectors.

---

"The attribute follows the same syntax as the CSS selectors, so that the
elements can be referenced by their name, id, or class, or a more
complex combination of the selectors."

The attribute, or each list value? Please clarify and add an example
showing the use of a list of selectors.

---

"If the attribute targets multiple elements in the host document, item
controls all of them based on the host document order."

How is the control based on the host document order?

---

"When the selector matches more than one element, an ordered list
ofelements is constructed."

...and the ordered list is ordered by what exactly? Is it "live" or not?

---

"The beginInc attribute increments the begin time of each of the
elements,but the first one, by the defined value. Note that the begin
time of thefirst element is never modified. The beginInc attribute has
to be apositive integer."

What important use-cases are addressed by the 'beginInc' attribute?
Please add an informative section describing that.

"each of the elements" is "each of the selected elements"? Clarify please.

Please define what happens if the beginInc attribute is not a positive
integer (e.g. a float value or a negative value)?

---

"Note that the begin time of the first element is never modified."

That's repeating the "but the first one" again, it's confusing.

---

"The item element defines one function: index()."

Is this to say that section 3.4 should be made informative? Please keep
all normative text in one place.

---

"Thus, it can be used to automatically generate index numbers for both
internal and external events within the begin, dur, or end attributes of
the item, animate, set, animateMotion, and animateColor elements."

Host languages may wish to add further attributes where it can be used,
please allow that. And the list of elements which it applies to should
of course also allow for host languages to add elements
(svg:animateTransform).

---

"The index() function has the format:index(<selector>, <indexStart>)"

Is extra whitespace allowed (start, middle, end)? What happens if the
comma is missing?

Please consult the CSS WG if you haven't already done so, to make sure
that comma is the best separator character for selectors.

---

"The <selector> parameter has to be a valid CSS selector, while the
<indexStart> parameter has to be a positive integer value."

Clarify what happens if the above conditions are false (each
individually or both at the same time).

---

"If there are no elements in the host document matching the CSS
selector, the index() function is not called."

Please clarify that it is a MUST requirement.

---

"If there are elements in the host document matching the CSS selector,
an ordered list of the elements is constructed. In this case, when an
element from the list is activated, the index() function returns the
index of such element within the list plus the <indexStart> value."

Please define the index start offset (0 or 1 usually). Here it might be
nice to point out something about negative <indexStart> and indexing.

The order of the selected list comment (mentioned in other comments)
applies here too.

---

"The item element can contain:
- time containers: seq, par, and excl
- prefetch elements
- animation elements: animate, set, animateMotion, and animateColor
- and other item elements"

Allow host languages to add elements here, e.g <svg:animateTransform> or
host language time containers.

---

"However, the direct child of the item element can only have one child
or none."

Why? It may have several, but timesheets MUST not process them. Clarify.

---

"All other children than the first one are ignored."

What if the first child is a textnode? Clarify that it's the first
element child.

---

"If the item element has several descendants they have to be included
within a child time container."

Why? Please clarify. Also, if this is a normative statement, please use
the keyword MUST.

---

"Furthermore, the parent item element limits the scope of the CSS
selectors of the descendant item, prefetch, animate, set, animateMotion,
and animateColor elements to match only descendant elements of the host
language elements selected by the parent item element, as described in
the SelectionMechanism section."

It's not clear to me why this has to be limited to only one step of
nesting. Since the need for limiting the scope of CSS selectors is
cited, why is it that one is prevented from further limiting the scope
by nesting item elements deeper?


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1921: SMIL TimeSheets 1.0 (namespace)
Commenter: Simon Pieters <simonp@opera.com> (archived message)
Context: in
http://www.w3.org/TR/2008/WD-timesheets-20080110/

2 Overview contains:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:smil="http://www.w3.org/ns/SMIL30">

But the SMIL namespace is "http://www.w3.org/ns/SMIL".
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1925: [Timesheets LC comment] Abstract and Introduction
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


It's not clear that setting the 'active' or 'inactive' status of an
element toggles its visibility. This should be stated in the abstract
or introduction.

The abstract should describe the primary use cases, which seem to be
slideshows and photo galleries. Are there other use cases, either now
or planned for future versions?

---

It would be useful to explain very early on, in the abstract or
introduction, that "active" and "inactive" refer (exclusively?) to
states of perceivability, and that the purpose of timesheets is to
switch between these states.

---

"XML-based languages"

Can timesheets be used with text/html documents? Maybe you should say
DOM-based syntaxes?

---

Throughout the document, it's sometimes unclear when you are making
normative statements. We suggest strict use of the RFC 2119 keywords
("MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL"), in either upper or lower
case, instead of looser terms like "are", "has to", etc. This will
clarify the spec for implementors, and will also make it easier to
develop a comprehensive test suite. We also recommend that you mark
informational asides as such. Subsequent emails will point out specific
instances that we feel need addressing, but there may be more.


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1936: [Timesheets LC comment] 5.1 Attributes
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


"The begin attribute supports offset and event values, "indefinite", or
a semi-colon separated list of values. All other values are not
supported. The allowed values and semantics of the begin attribute are
defined in the SMIL 3.0 Timing and Synchronization module."

Please add links to the definition of "offset" and "event" values.

Please consider allowing the full range of begin values, or provide
reasons why SMIL Timesheets needs to be different from the rest of SMIL
(and SVG).

Please clarify what happens if an unsupported value is encountered. Or
if is it intended that the host language defines it, please state that.

---

"The dur attribute supports the clock values, "media", and "indefinite".
The allowed values and semantics of the dur attribute are defined in the
SMIL 3.0 Timing and Synchronization module."

The listed values are exactly the same as in SMIL 3.0 Timing and
Synchronization specifies for dur. Repeated it here increases the risk
of errors and outdated definitions. We recommend pointing to the dur
definition and saying it MUST be exactly as defined there.

---

"The end attribute supports offset and event values, "indefinite", or a
semi-colon separated list of values. All other values are not
supported.The allowed values and semantics of the end attribute are
defined in theSMIL 3.0 Timing and Synchronization module."

Same comments apply here as for the 'begin' attribute.

---

"Since SMIL Timesheets does not include transitions, the
fill="transition"value of fill attribute is not supported. Also, since
the fillDefault attribute is not included in the SMIL Timesheets, the
fill="default" is interpreted the same as fill="auto"."

Note that the SMIL defaults are different from the SVG 'fill' attribute
defaults. See http://www.w3.org/TR/SVG11/animate.html#TimingAttributes.
That can be confusing, so please provide an example and some informative
text to explain this.

Why are there no transitions? This is something that authors will want,
and which is common in many script libraries (such as when a button
glows then fades when activated, or photo galleries blend between
images). Perhaps describing transitions in the form of opacity
animations and the like would be useful. If this functionality that is
intended for a later specification?

---

"The first attribute sets the current active child of a time
container"inactive". Then, it selects the first child element and sets
it "active". The first attribute can only be used for the excl time
container. The allowed value of the first attribute is a DOM event
[DOM2Events]."

Please clarify what it mean to set a time container to "inactive"/"active".

Please allow host languages to extend the set of allowed values to
include events that are not defined in DOM2Events.

---

"The prev attribute first checks, whether the current active child is
the first child. If not, it sets the current active child of a time
container "inactive". Then, it selects the previous child of the time
container and sets it "active". The prev attribute can only be used for
the excl timecontainer. The allowed value of the prev attribute is a DOM
event [DOM2Events]."

Please clarify that these attributes (first,next,prev,last) only operate
on elements, not on textnodes. As it is now it might mean for example a
previous child textnode.

Also it's not clear why the attribute has to be restricted to <excl>
only, we think just specifying that it only applies to <excl> might be
better. Host languages might want to reuse these attributes, so perhaps
leave that open too.

These comments apply to all of the first, prev, next, last attributes.

While the next, prev etc might be useful for creating a slideshow, it
seems to be lacking something like a "skip multiple", say next+10 or
prev-5 elements. Although this might be difficult to add as an
attribute, it shows that the current set of prev, next, first, last may
not cover all common use-cases, and that they should be thought over
once more to see if there's a better solution.



Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1926: [Timesheets LC comment] Editorial
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


Typos
-----
"a-temporal" -> "atemporal"
"Timeshets" -> "Timesheets"
"Timsheets" -> "Timesheets"
"Timesshets" -> "Timesheets"
"meadiaSize" -> "mediaSize"
"meadiaTime" -> "mediaTime"
"allways" -> "always"
"severall" -> "several"
"oredered" -> "ordered"
"attibute" -> "attribute"
"semi-colon" -> "semicolon"

Grammatical and Punctuation Corrections
---------------------------------------
"SMIL Timesheets includes the SMIL 3.0 PrefetchControl module and the
SMIL 3.0 BasicAnimation module is used for controlling animations." ->
"SMIL Timesheets includes the SMIL 3.0 PrefetchControl module, and the
SMIL 3.0 BasicAnimation module is used for controlling animations."

"On the other hand, the begin attribute of a children of a excl
timecontainer is "indefinite"." -> "By contrast, the begin attribute of
the children of a excl time container is "indefinite"."

"The par element short for "parallel", defines a simple time grouping in
which multiple elements can play back at the same." -> "The par element,
short for "parallel", defines a simple time grouping in which multiple
elements can play back simultaneously."

"checks, whether the current active child is the first child" -> "checks
whether the current active child is the first child"

---

There are several incidents of missing definite or indefinite articles,
or where the article or verb conjugation does not agree with the number.
Here are a few examples:
"The children of the seq element consider the end time of preceding
child as their syncbase."
"Figure 1: Timeline of a Timesheets"
"Host document's" -> "A host document's"
"By default the begin attibute of a children of a seq and a par
timecontainers is "0s"."


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1937: [Timesheets LC comment] 5.2 Elements
Commenter: Doug Schepers <schepers@w3.org> on behalf of S (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


The explanations of the par, seq and excl elements seem informative.
Please make them so, and add a normative statement saying that these
elements are defined in the SMIL 3.0 Timing and Synchronization module.

---

"The excl element defines a time container with semantics based upon
par,but with the additional constraint that only one child element may
play at any given time."

It's not clear to the SVG WG whether this is a constraint added by
Timesheets or by SMIL Timing and Synchronization.

---

"If any element begins playing while another is already playing, the
element that was playing is stopped."

Please clarify what it means that "playing is stopped". Is the timeline
paused, reset, or something else? What happens if the time first
animation is started again?

What happens if an animation is running in one "slide", and the user
navigates away, then returns? What state is the animation in?



Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1927: [Timesheets LC comment] Definitions
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


As with the SMIL specs themselves, a definition list would be very
helpful. Here are some terms that should be defined, either in this
document, or in some other document with a direct reference link:

* time container [1]
* syncbase [2]
* host language

[1] http://www.w3.org/TR/SMIL3/smil-timing.html#q167
[2] http://www.w3.org/TR/SMIL3/smil-timing.html#q159


In general, the SVG WG finds the SVG spec notation to be more readable
than SMIL Timesheets for all attribute values, and encourage the SYMM WG
to use similar notation in SMIL Timesheets. See for example:
http://www.w3.org/TR/SVG11/painting.html#MarkerElement


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1938: [Timesheets LC comment] 6 Prefetch
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


"In the SMIL Timesheets, the src attribute is replaced with the select
attribute."

Please clarify, this can be read as, "'src' is renamed 'select' and
accepts the same values as 'src'".

It's not clear from the section what exactly SMIL Timesheets uses from
the PrefetchControl module, and what it doesn't use.

A few normative references to SMIL 3.0 PrefetchControl would be helpful,
since the Appendix A lists PrefetchControl as an informative reference only.



Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1928: [Timesheets LC comment] Relationships to Other Specifications
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


1 Introduction

"An alternative to Timesheets is XHTML+SMIL [XHTMLplusSMIL] which gives
full SMIL functionality as in-line in non-SMIL XML documents. On the
other hand, SMIL itself gives full SMIL functionality as in-line
XML-based document."

The wording here is unclear, and seems to undermine the need for
timesheets when XHTML+SMIL already exists. Can you please clarify? The
first example seems to imply that timesheets can be used inline or
externally, but this passages seems to counterindicate that.

Also, what is the relationship of Timesheets and XHTML+SMIL to
HTML+Time? [1]

[1] http://www.w3.org/TR/NOTE-HTMLplusTIME




Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1939: [Timesheets LC comment] 7.1 Attributes
Commenter: Doug Schepers <schepers@w3.org> on behalf of SVG WG (archived message)
Context: in
Dear SYMM WG-

This is a Last Call review comment from the SVG WG on the SMIL
Timesheets 1.0 specification, W3C Working Draft 10 January 2008,
http://www.w3.org/TR/2008/WD-timesheets-20080110/ . Please let us know
if you have any questions by replying to www-svg@w3.org.


"If no explicit target is specified, that is, the animation element does
not specify the select attribute, the implicit target element is the
host language element or elements referenced by the parent or ancestor
item element."

Please define the term 'animation element'.

Please clarify what is meant by 'the implicit target element is the host
language element'.

'parent or ancestor item' seems to allow arbitrary depth nesting of <item>
is that intended?

Please clarify the order in which the implicit target element is resolved.

---

"The origin attribute specifies the origin of motion for the animation."

Note that origin has no meaning in SVG. Please add informative text and
an example showing that.

---

"Timesheets uses the select attribute to specify the target element."

The paragraph this sentence start seems to be informative, not
normative, and should be marked as such.


Regards-
-Doug Schepers, on behalf of the SVG WG
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-28

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org