Re: Reminder: Archive Module

Hi John,

thanks for editing the Archive Module.

• As indicated before, I think that a convenience function for
extracting ZIP archives to disk would be beneficial. I see three
reasons for this: Extracting files is one of the most frequent
operations done with archives. Next, a pure XPath or XQuery solution
is, by nature, pretty cumbersome and not intuitive. Last but not
least, we should provide a solution for extracting very large files,
as it’s pretty tricky to rewrite the example in 3.3, and related ones,
for streaming IO. However, I agree that is easy to find SoC arguments
against providing such a function.

• Another open issue is the handling of directories in archives. I
don’t have an easy answer for that, but we still need to find some way
to create empty directories via the Archive Module.

• Some additional errors could be added for handling unsupported
archive formats or algorithms, or entry descriptors (unless we want to
generally use FORG0006 for unknown function arguments)

Hope this helps,
Christian
___________________________

2013/10/21 John Lumley <john@saxonica.com>:
> May I remind the community that a sizeable draft EXPath module specification
> for archive manipulation
> was posted and announced three weeks ago. There are a number of
> module-detailed issues that would benefit from criticism, as
> well as some more fundamental issues about EXPath's posture regarding
> backwards (i.e. XSLT/XPath 2.0) compatibility. Your comments in either space
> are welcomed.
>
>
> A new draft EXPath module specification (*Archive*), to manipulate archive
> file formats, is announced, and is available at
>
>  http://expath.org/spec/archive
>
> This module is intended to replace (and generalise) the previous ZIP module
> of 2010, which we believe has not seen much real use.
> The specification contains a complete set of function definitions and use
> case examples, including generating EPUB documents, reading and analysing
> JAR files and extracting ZIP files to a file system.
>
> The specification draft contains a number of issues that will need
> discussion and addressing by the EXPath community, not least of which is how
> such a module (and future modules) are positioned with respect to new
> features in XLST/XPath 3.0. In this case the use of maps as one of the
> module's interfaces increases coherence considerably, but of course
> precludes use in 2.0 implementations.
>
> This specification is very much a /first draft/ (though reasonably complete)
> and we expect many comments and criticisms, and a number of redrafts before
> we achieve consensus. We look forward to your comments (which I'll begin to
> marshal into threads as they develop), both specifically in regards to the
> Archive module and those on the more general positioning of new EXPath
> modules in the XSLT/XPath specification space.
>
> John Lumley, Christian Grün, Matthias Brantner, Florent Georgesex
> --
> John Lumley MA PhD CEng FIEE
> john@saxonica.com
> on behalf of Saxonica Ltd

Received on Monday, 21 October 2013 11:55:13 UTC