RE: transition: ambiguate extensions to set of transitions

We're in agreement for the most part.  My only contention is that if they
are specifying a "burn" transition that is only supported on one player,
they should not be *forced* to namespace qualify it.

I expect that in order for extension transitions to work, there will be some
need to reference the extension in a document. E.g. in HTML documents, an
object can be declared that will install the extension transitions. In
Netscape, it would have a slightly different declaration, but the same
principle applies.  AFAIK, G2 supports some form of plug-ins as well.

If a document explicitly declares a set of extension transitions in this
manner, it does not matter if someone else builds another set of extensions
with a "burn" transition, because that extension set has not been bound to
this page.

In practice, it will be safer for authors to qualify the extensions.
However, since they will have to bind the prefix to some organization and
extension set anyway, this is just another way of declaring the extension
set.

You seem to be implying that namespace prefixes can be used as an
alternative to browser sniffing. That may be useful, but we expect third
parties to provide a lot of the transitions, and that as such the author
will have to bind the extension to the browser in any case. This in turn
will (sadly) require some other form of browser sniffing.  

I wish that some alternative to object for code download was just supported
everywhere, and that some sort of content negotiation existed to get the
right version of the code for the os/app.  However, that problem remains
unsolved.  For the time being, people have to declare the object, and so
they should not also have to bind the namespace. If you insist on this, then
we have to state that transition extension mechanisms must include a binding
of a namespace to the extension transitions, so that your described
mechanism will work.

I see value in the mechanism you propose, but I fear that it may cause
problems as well (I cannot name one know, but I think there may be something
lurking out there). Is it a problem to not *require* namespace
qualification?  XMLNS just says it is up to the document/browser to bind a
name. What is wrong with that?

Thanks - Patrick

> -----Original Message-----
> From: Philipp Hoschka [mailto:ph@w3.org]
> Sent: Monday, October 23, 2000 10:20 AM
> To: Patrick Schmitz
> Cc: www-smil@w3.org
> Subject: Re: transition: ambiguate extensions to set of transitions
> 
> 
> 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 14:44:29 UTC