- From: Dave Pawson <dave.pawson@gmail.com>
- Date: Wed, 25 Apr 2007 14:01:45 +0100
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
On 24/04/07, Norman Walsh <ndw@nwalsh.com> wrote: > / Dave Pawson <dave.pawson@gmail.com> was heard to say: > | Would you consider unzip as an optional component please. > > Tricky. > > $ unzip -v XProc.odp > > Archive: XProc.odp > Length Method Size Ratio Date Time CRC-32 Name > -------- ------ ------- ----- ---- ---- ------ ---- Pictures/1000000000000555000000448B6CAF0B.png > 126345 Stored 126345 0% 10-02-06 14:45 d7344633 Pictures/100000000000040000000300627D049C.gif > 44177 Defl:N 4229 90% 10-02-06 14:45 4a7f0be5 content.xml > 62677 Defl:N 5342 92% 10-02-06 14:45 358ac888 styles.xml > 1231 Stored 1231 0% 10-02-06 14:45 a890e0c9 meta.xml > 10386 Defl:N 10391 0% 10-02-06 14:45 863078be Thumbnails/thumbnail.png > 10760 Defl:N 1563 86% 10-02-06 14:45 c1cd75ec settings.xml > 2198 Defl:N 389 82% 10-02-06 14:45 729b14bd META-INF/manifest.xml > -------- ------- --- ------- > 261271 152989 41% 17 files The primary ones I'm interested in are content.xml and styles.xml though images will be wanted for a full process, so I guess your selection idea would meet the needs? How reasonable is it to assume that a user knows the contents of the zip file? Without such knowledge he/she is poking about with a stick in the dark? In which case I'd suggest a list of 'required' files be presented for unzip. > could return an XML manifest of the ZIP file. And > > <p:unzip> > <p:option name="href" value="XProc.odp"/> > <p:option name="document" value="content.xml"/> > </p:unzip> > > could return the selected document, failing if the document isn't > XML. > > Is that what you had in mind? That would leave relative path issues Norm? Provide the full path within the zip? But yes, that would meet my needs perfectly. regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
Received on Wednesday, 25 April 2007 13:01:57 UTC