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-1929: [Timesheets LC comment] Examples and Figures
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 figure numbering scheme is broken, all figures are listed as figure 1

As a general comment, the diagram images do not have adequate alt text,
and the first one contains a code snippet that could be extracted and
included in the main body as text. Members of the SVG WG could make SVG
versions of the diagrams if desired, which might be more accessible.

The examples all use the "smil:" prefix; this is not necessary. It's
extra characters to type, and also adds to the filesize. Please remake
the examples so that the default namespace is opened on the topmost SMIL
<timesheet> element.

The example of the first, prev, next, and last attributes would be more
clear if the button ids were not "first", "prev", "next", and "last"; it
may lead to the mistaken impression that those are somehow magic IDs or
values. Maybe name them "start", "back", "forward", and "end"?


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

Comment LC-1940: [Timesheets LC comment] 7.2 Elements
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 SMIL Timesheets includes all elements of the SMIL 3.0
BasicAnimationmodule: animate, set, animateMotion, and animateColor."

Please allow host languages to add elements, e.g <svg:animateTransform>.

---

"The animateMotion element moves an element along a path. It is defined
inthe SMIL 3.0 BasicAnimation module."

Actually it's not fully defined, it requires a host language to define
it further. The <svg:animateMotion> element is fully defined however,
and it's different from the <smil:animateMotion> definitions. The SVG
WG, and SVG authors, would expect to be able to use all of
<svg:animateMotions> functionality in SMIL Timesheets, such as the 'd'
attribute, the <svg:mpath> element etc.


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

Comment LC-1945: Theora and SVG:
Commenter:
Context: in
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1930: [Timesheets LC comment] Visibility
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 case of an element in the document that is not referenced by the
Timsheets, the element will be visible as dictated by the stylesheet."

Stylesheet == timesheet? This above is unclear to me. In SVG the
visibility may be defined not in a CSS stylesheet but in the document
itself, either by <style> elements, by 'style' attributes, or by
presentation attributes.

Could this be better worded, "In the case of an element in the document
which is not referenced by the Timesheets, the visibility of that
element will be dictated by the default visibility of host-language, or
as defined by the styling mechanism."?

---

"By default the element will remain visible all the time."

Define "visible".


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

Comment LC-1941: [Timesheets LC comment] 8 Integration with CSS Layout
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.


Where is the normative text for CSS Layout integration?

Can SMIL Timesheets be used in HTML+CSS with predictable and defined
results?


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

Comment LC-1946: Theora and SVG:
Commenter:
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-1931: [Timesheets LC comment] External Linking
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.


This specification shouldn't define the semantics of how a host
languages references the timesheet. (Option, neither would be defined
outside either document, in a manifest. , but optionally may be defined
by the host language.

While it's good to provide well-defined examples for a host language to
consider, these definitions should be a MAY or RECOMMENDED, or be
informative, not normative.

---

Please define what happens when multiple timesheets interact, such as
when several timesheets are referenced from the same document.

---

Can a timesheet import or reference another timesheet, to allow modular
timesheets and reuse? If not, why not? If so, what are the
implications for the timelines?

---

4.1 The timesheet element
-------------------------
"The timesheet element is located in the head section of the document.
It defines a parent container for other SMIL Timesheet elements."

Please change this to allow the host language to define that "head
section". In SVG there's no "head" element, the closest thing is
<defs>, which can occur any number of times anywhere in the document.

A better definition would be to say that the <timesheet> element can
occur anywhere that the <style> element can. It may be that host
languages will want to define this further though, especially in the
cases where there is no <style> element, so please allow for that too.

"The timesheet element defines two attributes: src and media."

This makes it stand out in SVG, since SVG uses xlink:href for other
references.

---

"The src attribute tells the location of an external timesheet. With
this attribute a common timesheet can be reused in multiple documents.
The attribute must contain a valid URI."

What happens if the timesheet element has no src attribute? What
happens if the attribute contains an invalid URI? What is a valid URI in
this context? Please add a normative reference to "valid URI".

Why is there no example and spec definition for how to use
<?xml-stylesheet?> for including a SMIL Timesheet? Please add that.

We don't see the need for having the src attribute on <timesheet> given
that <?xml-stylesheet?> can be used instead, and since the
<smil:timesheet> is limited to referencing SMIL Timesheets it's not
re-usable for other types of stylesheets. Please consider removing the
src attribute altogether. In HTML the <link> element might be used
instead, see http://www.w3.org/TR/html401/struct/links.html#edef-LINK.

---

"The media attribute is used for selecting the most suitable timesheet
for the current media device."

That's informative, make it clear.

---

"It works in the same way as the @media rule in the CSS stylesheets [CSS2]."

If that's a normative statement please reword it to say it MUST be
exactly as defined in CSS2.

---

"The media attribute contains a comma separated list of CSS media types."

Informative or normative? Is that not defined in CSS2?

---

"The timesheet timing and animation information is applied to the host
language document, only when the target device media type matches one of
the media types defined by the media attribute. If the media attribute
isnot defined, the default value is "all"."

Normative? Again isn't this defined in CSS2?

---

"The timesheet element contains the par, seq, and excl time containers."

What happens when it contains something else? For example if it was to
contain one of SVG's declarative animation elements?

---

"The semantics and restrictions are specified in the the time container
attributes."

Semantics and restrictions of what? The timesheet element or the par,
seq, and excl elements? Please clarify.

---

"In addition, it contains the item and prefetch elements. Finally, it
also contains the animation elements: animate, set, animateMotion,
andanimateColor."

Umm, why not list all of the elements allowed in one sentence? This is
simply confusing. Please allow the host language to extend the elements
allowed. In SVG there's the <animateTransform> element which is very
useful to include here.

Please explain what should happen when a timesheet is in conflict with a
host language animation? Also if another SMIL animation being applied on
the same element that is animated by a timesheet - how do they interact?



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

Comment LC-1942: [Timesheets LC comment] Appendix A. References
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.


"This section is informative.
E.1 Normative References"

That's a contradiction. Please fix.

Please reference CSS 2.1 and DOM 3 Events, or explain the rationale for
not doing so.

All of the SMIL 3 modules that are normatively referenced in the spec
should be listed as normative references.



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

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)

1-20 21-28

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.47 2015-01-05 13:17:17 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org