W3C home > Mailing lists > Public > www-smil@w3.org > January to March 2000

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

From: Cohen, Aaron M <aaron.m.cohen@intel.com>
Date: Tue, 25 Jan 2000 11:12:19 -0800
Message-ID: <D5E932F578EBD111AC3F00A0C96B1E6F04068571@orsmsx31.jf.intel.com>
To: "'Philipp Hoschka'" <ph@w3.org>, Dmitry Beransky <dberansky@ucsd.edu>
Cc: www-smil@w3.org

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

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.

> -----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
Received on Tuesday, 25 January 2000 14:12:38 UTC

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