RE: deprecate application/smil ? (was: Re: request for applicatio n/smil)

Steve:
Thanks for the reply but I'm a little confused. I did not suggest
deprecating application/smil now, and I do not that that would be a good
idea.

My response was on the order of:
1. register application/smil now
2. wait for the xml media types proposal to get to rec status
3. register an additional mime type compliant with the above proposal
4. deprecate the old mime type, which means that the old type must still be
supported, but we recommend switching to the new mime type.

Is this strategy more acceptable?
-Aaron


> -----Original Message-----
> From: Steve Jacobson [mailto:stevej@real.com]
> Sent: Tuesday, February 01, 2000 1:41 PM
> To: www-smil@w3.org
> Subject: RE: deprecate application/smil ? (was: Re: request for
> applicatio n/smil)
> 
> 
> Aaron, et. al.
> 
> We do not consider deprecating application/smil a viable 
> option at this time.  Creating a
> new MIME type breaks applications until all components of the 
> application have been updated
> 
> to support the new MIME type.  Updating an install base the 
> size of the current SMIL user
> base is non-trivial.  It is both expensive and time consuming 
> to support the change, update
> 
> doccumentation, and educate users.
> 
> Furthermore, the XML Media Types is in draft form.  It will 
> still be some time before this
> is finalized.  This change will be expensive enough to do 
> once - to risk having to do it
> twice is too much.  A gradual transition to a new MIME type 
> could be considered, but it is
> simply unacceptable to deprecate the existing SMIL MIME type.
> 
> -Steve Jacobson
> 
> >
> 
> > RE: deprecate application/smil ? (was: Re: request for 
> applicatio n/smil)
> >
> > From: Cohen, Aaron M (aaron.m.cohen@intel.com)
> > Date: Tue, Jan 25 2000
> >
> > *Next message: Lloyd Rutledge: "Multimedia on the Web 
> Workshop at WWW9"
> >
> >    * Previous message: Fabienne Hadkova: "A question"
> >    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >    * Other mail archives: [this mailing list] [other W3C 
> mailing lists]
> >    * Mail actions: [ respond to this message ] [ mail a new topic ]
> >
> >   
> --------------------------------------------------------------
> ----------
> >
> > Message-ID: 
> <D5E932F578EBD111AC3F00A0C96B1E6F04068571@orsmsx31.jf.intel.com>
> > From: "Cohen, Aaron M" <aaron.m.cohen@intel.com>
> > To: "'Philipp Hoschka'" <ph@w3.org>, Dmitry Beransky 
> <dberansky@ucsd.edu>
> > Cc: www-smil@w3.org
> > Date: Tue, 25 Jan 2000 11:12:19 -0800
> > Subject: RE: deprecate application/smil ? (was: Re: request 
> for applicatio      n/smil)
> >
> > Phillip:
> >
> > I'm not an implementor, but here's my two cents.
> >
> > Please fill me on on mimetype policy details. Can we not 
> have two mimetypes?
> > Doesn't deprecate mean that you keep the old one around, 
> but encourage the
> > use of the new one? How does that cause a problem?
> >
> > I don't know whether not having "xml" in the mimetype 
> "seriously hurts
> > SMIL's usefulness" because I don't have a clear indication 
> on how often SMIL
> > documents will be processed as XML. However, it seems that 
> we should allow
> > for this if at all possible, in order to leverage current 
> and future XML
> > technologies.
> >
> > Your idea of registering application/smil and 
> application/smil-xml in the
> > future when the xml naming convention is established 
> implies that we can
> > have multiple mimetypes for a single document type and 
> seems like the right
> > way to go. I don't see what it buys us not to not have any 
> registered mime
> > type until the xml mimetype naming convention is 
> standardized. And I also
> > don't see the value in registering what we guess _might_ 
> become the standard
> > format before the naming convention is standardized.
> >
> > Since we have an installed base, registering that makes 
> sense. When the xml
> > mimetype naming is resolved, we can register that one too, 
> and deprecate the
> > old one.
> > -Aaron
> >
> > > -----Original Message-----
> > > From: Philipp Hoschka [mailto:ph@w3.org]
> > > Sent: Tuesday, January 25, 2000 2:43 AM
> > > To: Dmitry Beransky
> > > Cc: www-smil@w3.org
> > > Subject: deprecate application/smil ? (was: Re: request for
> > > application/smil)
> > >
> > >
> > > Dmitry,
> > >
> > > I am personally still not sure that deprecating 
> application/smil is
> > > a viable option given the installed base, and that this MIME type
> > > has been chosen by consensus a couple of years ago. I have the
> > > feeling that we can move to application/smil-xml once Makoto's
> > > proposal has actually achieved standards status, and the 
> developments
> > > you predict in your message below have actually happened.
> > > That would be
> > > a seperate MIME type registration.
> > >
> > > However, I would be interested in comments by 
> implementors on this,
> > > before moving on:
> > > - Should we not register application/smil, and move to
> > > application/smil-xml
> > > right away ?
> > > - Do other people believe that sticking with application/smil
> > > will "seriously hurt SMIL's usefulness in the future", given the
> > > arguments
> > > below ?
> > >
> > > -Philipp
> > >
> > > Dmitry Beransky a écrit :
> > > >
> > > > Phillip,
> > > >
> > > > I saw the thread on ietf-xml-mime [1] in which you discuss
> > > SMIL's MIME type
> > > > with Makoto Murata.  While I understand your reasoning, I
> > > still think it a
> > > > bad idea to not to push for a more complaint MIME type.
> > > >
> > > > I'm currently writing a generic XML processor capable 
> of serving and
> > > > updating arbitrary portions of an XML tree (with 
> complete locking
> > > > capabilities, etc.).  I pretty much would like my server to
> > > work with any
> > > > XML file, but if we continue the trend that SMIL is
> > > setting, the only way I
> > > > can make sure I can handle an arbitrary XML file is by
> > > enumerating all
> > > > possible MIME types.  This is not a scalable solution.
> > > >
> > > > As XML matures, I can see an increasing number of 
> applications that
> > > > streamline storage/retrieval of XML-based documents.  As
> > > soon as XML QL
> > > > group is done with its work, we will also see a surge of XML
> > > > databases.  All these applications will rely on MIME types
> > > to recognize XML
> > > > documents.
> > > >
> > > > While keeping SMIL's type as application/smil will satisfy
> > > most people's
> > > > current needs, I think it will seriously hurt SMIL's
> > > usefulness in the
> > > > future, especially in high production environments where
> > > batch processing
> > > > is a must.
> > > >
> > > > Regardless of whether Makoto Murata's proposal [2] shall be
> > > finalized or
> > > > not, IMHO it is clear that there will be a standard
> > > mechanism in practice
> > > > for assigning mime types to XML based documents.  I 
> think that your
> > > > proposal should deprecate application/smil in favor of such a
> > > > mechanism.  This way, SMIL tool developers will have enough
> > > time to adjust
> > > > and, hopefully, we can have a smooth transition from
> > > application/smil to
> > > > applications/smil-xml or whatever other recommendation
> > > ietf-xml-mime WG
> > > > will come up with.
> > > >
> > > > Best regards
> > > > Dmitry Beransky
> > > >
> > > > [1] 
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00315
> > > [2] http://www.imc.org/draft-murata-xml
> >
> >
>
>   ------------------------------------------------------------------------
>
>    * Next message: Lloyd Rutledge: "Multimedia on the Web Workshop at
WWW9"
>    * Previous message: Fabienne Hadkova: "A question"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]

--
Steve Jacobson - Product Manager - RealNetworks, Inc.
2601 Elliott Ave, Seattle, WA 98121
ph: 206.674.2451 - stevej@real.com - http://www.real.com
Fax: 206.674.2591 - Cell: 206.310.7760
text page: pagestevej@real.com

Received on Tuesday, 1 February 2000 17:11:42 UTC