OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] auto-play presentation file format like PPS - MIME typeparameter


Hi Warren,

See my another mail in this loop. I prefer to call option name "shortcut-open-mode" since this attribute should be restricted in the scenario that user double-click or select/enter the document directly from OS shell, otherwise, it seems no real meaning. Thanks.


Best Regards,

Mingfei Jia(¼ÖÃ÷·É)
IBM Lotus Symphony Development
IBM China Software Development LAB, Beijing
Tel: 86-10-82782244-2493 Fax: 86-10-62982924
NOTES:Ming Fei Jia/China/IBM E-mail: jiamingf@cn.ibm.com
Address: 4/F, DeShi Building No.9, East Road, ShangDi, Haidian District, Beijing 100085, PRC
Inactive hide details for Re: [office] auto-play presentation file format like PPS - MIME type parameterRe: [office] auto-play presentation file format like PPS - MIME type parameter




Re: [office] auto-play presentation file format like PPS - MIME type parameter

Warren Turkal

to:

dwheeler

2008-04-08 01:33


Cc:

office





2 comment below.

On Mon, Apr 7, 2008 at 8:41 AM, David A. Wheeler <dwheeler@dwheeler.com> wrote:
> I propose the following, to be added to the end of the "MIME Type Stream" section of the ODF document:
>  "If the top-level document has a non-default 'autoplay' value, then the MIME type SHOULD have "; autoplay=" followed immediately by the autoplay value (such as "view"), creating a MIME parameter.  If the autoplay MIME parameter is included, it MUST be the first parameter of the MIME type.  This enables operating system launchers to launch a different program (by default) for 'autoplay' files, without requiring them to decompress or parse the XML."
>
>  This would enable users to automatically run a "viewing" program that might be very different from the usual editor when handed an autoplay file.
>
>  Note: Change "autoplay" and "view" to whatever is agreed on.


I don't believe that "autoplay" captures this concept very well. Let's
call it something like "suggested-view-type" or "preferred-view-type"
instead.


>
>  =================
>
>  Background:
>  * In most operating systems, if you double-click on a file, it uses a "launcher" to determine the correct application to use, and then runs that application.
>  * Launchers must determine what "type" of file you've selected.  This determination is typically done using simple criteria such as file extension and/or magic numbers in fixed positions of the file.  They generally DON'T or CAN'T do complex XML parsing, decryption, or decompressing.
>  * To make it easy to determine what to launch, the zipped OpenDocument format ALREADY includes a more detailed MIME type in a fixed position in the zipped (packaged) version).  ODF spec version 1.1 chapter 17 says: "If a MIME type for a document that makes use of packages is existing, then the package should contain a stream called "mimetype". This stream should be first stream of the package's zip file, it shall not be compressed, and it shall not use an 'extra field' in its header (see [ZIP]). The purpose is to allow packaged files to be identified through 'magic number' mechanisms, such as Unix's file/magic utility. If a ZIP file contains a stream at the beginning of the file that is uncompressed, and has no extra data in the header, then the stream name and the stream content can be found at fixed positions. More specifically, one will find: a string 'PK' at position 0 of all zip files, a string 'mimetype' at position 30 of all such package files, [and] the mimetype itself at position 38 of such a package."
>  * The MIME spec (IETF RFC 2046) permits "parameter options" after the main MIME type.  Just add ";" followed by semicolon-separated name=value pairs.  It's specifically for things like determining what application to launch
>  * Since launchers typically look at fixed positions, we can REQUIRE that it be at the initial position for it to have effect.
>
>  Rationale:
>  * Since it's _derived_ from the XML data, you can decompress the data, edit it, and package it back up again without loss.
>  * Since it's in a fixed location in the ZIP file, a launcher doesn't need to process the XML to figure out what application to launch.  If there's a separate viewer, it can use it.
>  * Since it's part of the MIME type, using the usual "parameter" fields of MIME, systems which launch depending on the MIME type can use this easily.
>
>  My theory is that the auto-play information is part of the XML, and can be included on any type of document.  When the file is zipped up, the "mimetype" stream has to be created first anyway... the application can simply append this parameter if it's set on the original document.  When the launcher starts, it can look for this value.


I do not believe that "autoplay" on all document types makes sense. I
think there should be a view profile (e.g. "presentation-autoplay") in
the mime type and a configuration section for the view profile in the
manifest..


wt

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]