- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Tue, 9 Oct 2007 06:39:44 -0700
- To: "Marcos Caceres" <marcosscaceres@gmail.com>
- Cc: "public-appformats@w3.org" <public-appformats@w3.org>
- Message-ID: <OF5FED4524.319CB976-ON8825736F.004993C4-8825736F.004B0CB8@us.ibm.com>
Hi Marcos, This is likely to be an issue with many different opinions. There are actually two questions here. First, should there be a manifest file that lists the contents of the ZIP package? Let's assume the answer is yes. Then, you probably want to have an attribute such as 'type' that defines the MIME type of each particular file such as you describe below. My personal opinion is that it is always better to KISS, which translates into standards groups holding a ruthless sword that battles against feature creep of non-critical features, and in my mind manifest files are non-critical in many common workflows because the ZIP file itself has a directory and because the most common payload format, HTML, works on the Web very well without manifest files. My pragmatic proposal would be to define the file format for the manifest and define a standard location and name for the manifest within the package, but make it optional. In other words, manifests are not required but if present must conform to the spec. One more thing. If possible, to accelerate time to market and industry adopton, I would push the manifest file out of version 1.0, but have the 1.0 specification state reserve a future location for the manifest file. Second, some people will argue that ZIP packaging would benefit from a feature that associates particular extensions with particular MIME types. For example, all *.png files should be treated as PNG files. These associations tell the user agent about the file handling expections from the author that created the package. Obviously, if you have such a feature to map extensions to MIME type, then the need to have a 'type' attribute in the manifest file becomes less critical. If anyone proposes such a feature, I would pull out the ruthless sword and not pursue this in version 1.0. Overall, I suggest focusing on KISS and holding up the ruthless sword, especially since so many of the widget systems are based on browser technologies. A common workflow will be building a mini Web application using HTML+JS+CSS+DOM+etc., creating a config file, and then just ZIP'ing it up. Don't add complications to that workflow if you can avoid it, else the industry will be disinclined to adopt it. Jon "Marcos Caceres" <marcosscaceres@g mail.com> To Sent by: "public-appformats@w3.org" public-appformats <public-appformats@w3.org> -request@w3.org cc Subject 10/08/2007 11:47 [Widgets] Manifest format PM Hi, I'm wondering if we should define a simple manifest format that authors can optionally use in a widget package (manifest.xml or as part of config.xml). The purpose of the manifest format would be to associate files in the zip archive with media types (particularly for cases where the file extension may be ambiguous, unassociable, or missing). For example: <?xml version="1.0"?> <manifest xmlns="http://www.w3.org/ns/widgets"> <file path="/data/output.json" type="text/javascript"> <file path="/graphics/graph.data" type="image/png"> <file path="/audio/music" type="audio/mpeg"> </manifest> FWIW, OOXML-OPC, ODF, and OCF define a manifest format. Kind regards, -- Marcos Caceres http://datadriven.com.au
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic26268.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 9 October 2007 13:41:09 UTC