RE: Feedback on Internet Media Types and the Web

+zip might be useful for scanning, transformations, etc.
(if only there were some reliable way of determining the
MIME types of the subsidiary components.)

The only problem with +zip is that some zip-based formats
are more sensitive than others to things like component
reordering, application of different zip compression modes,
equivalence of file-system unpacked and packed representations,
etc.

There are several "zip" profiles in use so that getting
agreement on what can be assumed by "+zip" might be harder.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Thursday, February 10, 2011 6:58 AM
To: julian.reschke@gmx.de
Cc: Eric J. Bowman; Larry Masinter; www-tag@w3.org
Subject: Re: Feedback on Internet Media Types and the Web

On Thursday, February 10, 2011, 1:53:59 PM, Julian wrote:

JR> My understanding is that we only need to define a notation if there's a
JR> common way to handle those media types. I can see that for +xml and 
JR> +json, but I am not so sure about +zip...

I agree that the benefit of a suffixed notation +toto is that some class of handling can be done for all foo/bar+toto even if you don't recognise bar (or foo).

For +xml, that handling is
- parsing
- well formedness checking
- validation
- looking for namespaces you recognise
- handing a dom to some other process

For +json I guess it would be
- convert to an internal JavaScript structure
- throw exceptions if malformed
- pass to some other process

For +zip:
- display contents of zipfile (as a tree-like filebrowser)
- look for particular things inside (manifest.xml)
- offer to extract some, rather than all, of the contents

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 10 February 2011 15:32:02 UTC