Forwarded message 1
Sally, Philipp:
Even if I realize this is a bit too late, I nevertheless wanted to
contribute our view to the SMIL discussion. I guess it may be useful anyway.
The reason for being late is that only very recent changes in Telecom and
CSELT have allowed us to put more effort in the W3C activities, thus we are
very likely to be more active in the future, and to take part to the
technical discussion. For SMIL (and similar activities) a very
knowledgeable person, Pietro Marchisio, will work part-time for W3C
activities. Pietro has, for example, a vaste background on MHEG. The
technical contribution hereby attached comes from him. It gives also a vote
indication, even if (as I already told) we know it's late. Use it for what
it's worth.
Franco.
---------------------------------
CSELT votes 'yes' to the SMIL proposal, and provides some comments that
are attached below.
Concerning the recent debate, and regarding one of the most controverial
points - SMIL layout overlaps with HTML/CSS layout - CSELT does not see
any problems in the current SMIL approach.
In fact, the lihghtweight layout specification would certainly be a
means to sooner achieve significant interoperability results.
Referring to the fact that SYMM group might have 'overstepped charter',
CSELT suggestion is to consider the specification on the basis of its
value as a vehicle for achieving interoperabiliy of simple applications
on the WEB. This really is an added value. No multimedia working group -
i.e. MHEG-1, MHEG-5, MPEG-4 - were able to precisely define their
charter before starting technical work.
Best Regards,
Pietro Marchisio
CSELT - Internet and Multimedia Services
=======================================================================
CSELT's comments to SMIL 1.0
EDITORIAL ISSUES
1) More factorization of common parts of the specification. Likewise
there is a common descrition for all "Media object elements", I would be
in favour of specifying only once the properties common to the 'par
Element' (4.2.1) and the 'seq Element' (4.2.2).
2) Specification more self-contained. When references to external
concepts are provided, a brief explanation in the document would improve
understanding. For example, a brief introduction of what "The a Element"
(4.5.1) is, is missing in the specification.
3) More direct and formal style in certain parts, trying to better
separate semantics of the specification from implementation cues. For
example in 4.2.3. (Media Object Elements:...), 4th paragraph, would
sound better if turned into a positive statement:
"The 'type' attribute provides information on the encoding algorithm of
the content data. The aim is to avoid the player to derive the encoding
algorithm from the name of the media object element. ... ".
MINOR TECHNICAL ISSUES
4) Semantics never should be 'implementation dependent', the effect of
the run-time presentation is. This is to say that a statement of the
type: "For media object elements, the semantics are implementation
dependent" (4.2.1/element-event value/clock-val) might give the
impression of a somewhat imprecise specification.
However, the specific case seems quite delicate. Why not to let the
decision to the author, by providing a defaultable attribute that allow
him to choose between 'effective begin' and 'media time' ?
5) There are no possibilities for the author to preload certain content
data before starting the presentation.
6) In 3.3.1 (The region Element), fit attribute, I propose to add a new
entry, which is
- tile: replicate the visual media object up to the right and bottom
end of the region element. This makes sense only for fixed media
objects, typically a bitmap. This allows a region to serve as a texture
background generated from a small bitmap
MORE RELEVANT TECHNICAL ISSUES (to be considered for further extensions,
e.g. SMIL 2.0)
7) Support for nested regions, with possibility of positioning a
child-region relatively to its parent-region
8) Support for changing geometry (position and size) of a region during
the presentation (e.g. 10s after starting the presentation of a video,
change the position of a bitmap
9) Possibility of performing the above transformation as a progressive
effect (e.g. 10s after starting the presentation of a video, move
progressively the video to a new position where the movement is
performed in 5sec)
Features 8 and 9 might be implemented by adding the 'action' element,
with the attribute 'target' that is the element on which the action's
effect is performed.
For example:
<par>
<video id="a" ...
<action target="a" begin="10s" dur="5s" left="200" top="200">
</par>
means that: after 10s, moves video "a" from its current position to the
position (200, 200). The effect of moving is performed gradually in 5s.
default: dur=0s.
======================================================