W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2000

Re: transition: ambiguate extensions to set of transitions

From: Philipp Hoschka <ph@w3.org>
Date: Mon, 23 Oct 2000 19:20:22 +0200
Message-ID: <39F47356.25B5562C@w3.org>
To: Patrick Schmitz <pschmitz@microsoft.com>
CC: www-smil@w3.org
Patrick,

see below

Patrick Schmitz a écrit :
> 
> This can be allowed, but should not be required.  If a given player does not
> support plug-in transitions or there are no plug-in transitions installed by
> the document, authors should not be required to qualify all the transitions
> supported by the player by default.

Not sure if I read this right, but you seem to imply that use of 
transition is player-specific, i.e. authors write documents with
transitions
to play back on one particular player, and not on any player that
supports
SMIL transitions.

I am not familiar with all the details of the transition spec, but if 
this is true, I guess we have a bigger problem than just disambiguating 
transition extensions. I think that the transitions should not be 
a player-specific technology, but that a document containing transitions
should play back with those transitions on any player.

I'm nearly sure that there is a misunderstanding somewhere - could 
you clarify ?
 
> Note that extension transitions should only be recognized if they are bound
> by the document, and thus the author knows in advance whether or not there
> will be any naming conflicts. The only requirement is that the author
> actually reads the documentation for transition support, which is not
> unreasonable.

Again, I'm not sure if I understand this correctly. You seem to be
saying that authors should only disambiguate transition names if
there is naming conflict in the document that they are writing, i.e.
if the document uses two transitions with the name "foo", but with 
different semantics. I think this would lead to issues for 
interoperability. 

Assume that player A defines an extension transition
named "foo" to mean a fade to black, and that player B defines
an extension transition "foo" to mean a dissolve (both of those
are supported by the SMIL transition spec, AFAIK, so no need to define
an extension - these are just examples). Assume further that an
author writes a document for player B, using "foo" transitions,
i.e. dissolve. When this document is played back on player A,
all the "dissolve" "foo" transtions would now become
fade-to-black, probably to the dismay of the author and any 
viewers. Disambiguating the "foo" names avoids this problem.
 
> > -----Original Message-----
> > From: Philipp Hoschka [mailto:hoschka@yahoo.com]
> > Sent: Friday, October 20, 2000 4:42 PM
> > To: www-smil@w3.org
> > Subject: transition: ambiguate extensions to set of transitions
> >
> >
> > (last call comment)
> >
> > The transitions draft currently specifies no method
> > that allows to avoid nameclashes for "private"
> > transistions:
> >
> > http://www.w3.org/TR/2000/WD-smil20-20000921/smil-transitions.
> html#TransitionEffects-Extending
> >
> > In other words, two implementations can use the
> > same name for a new transition, but they would result
> > in completely different transitions.
> >
> > This can be resolved by using a namespace-based
> > solution, which is already used for events
> > http://www.w3.org/TR/2000/WD-smil20-20000921/smil20-profile.html#q21
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Messenger - Talk while you surf!  It's FREE.
> > http://im.yahoo.com/
> >
Received on Monday, 23 October 2000 13:22:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:23 UTC