Re: Archive Module -revival

It might be good keeping sync with
http://gildas-lormeau.github.io/zip.js/core-api.html

Just saying

Mohamed


On Tue, Feb 4, 2014 at 11:52 AM, John Lumley <john@saxonica.com> wrote:

>  Gentlefolk,
> The Archive Module http://expath.org/spec/archive has been somewhat put
> on the back burner since the September draft while getting the Binary and
> File modules close to or at 1.0 status, but it's about time it got a little
> more attention.
>
> Some discussion took place in November and December (with an unpublished
> Editor's draft) suggesting the following easy changes:
>
>    1. Adding functions arch:to-files() and arch:from-files() to give
>    single-call transfers between archive and file directory trees. [These are
>    effectively the examples in the Sept. draft, with some correctons and made
>    more complete. It has been suggested that a 'target-path' argument should
>    be added to arch:to-files().]
>     2. Improving the actions dealing with empty 'directory' entries.
>    3. Adding some further convenience functions for content, such as
>    arch:text() which is effectively bin:encode-string(), or arch:xml()which is a compound
>    bin:encode-string(fn:serialize()). [Similar for arch:html() with
>    different serialization controls.] Both of these would require dependency
>    on the Binary module, unless someone wishes to rewrite their own
>    implementation.
>
> The first two have already been altered on the Editor's draft. Views on
> the third are welcome. Florent suggested examples:
>
>    arch:create(
>        ('mimetype', 'META-INF/container.xml', ...),
>        (arch:text($mimetype), arch:xml($container), ...))
>
> The ideal solution, from an API and usability point of view, would be something like:
>
>     arch:create((
>        arch:text-entry('mimetype', $mimetype),
>        arch:xml-entry('META-INF/container.xml', $container),
>        ...))
>
> and this last example becomes "easy" to represent if arch:create() accepts maps.
>
>  Whilst the first form for arch:create() works easily with the current
> 'non-map' archive mechanism, of two parallel sequences, the second does
> not. It could conceivably work for a single argument form of arch:create($in
> as *item()**), taking the members of $in by pairs, assumed to be (
> *xs:string,xs:base64Binary*)*, and arch:*xxx*-entry() producing such a
> pair. Not the most elegant, but certainly coherent. If you really wanted
> the first argument could be treated polymorphically - if you want 'per
> entry' control on properties, an element structure could be used and
> implementations make type-directed choices - but I'd rather not open that
> can of worms.
>
> Excluding the use of maps, other (minor) issues that are outstanding
> include:
>
>    1. Whether options for an archive should be read or set through
>    attributes on an element, or child elements, viz <arch:options
>    format="zip"> or <arch:options><arch:format>zip</ ..  Currently
>    <arch:entry> uses attributes. We should perhaps try to be consistent
>    and establish a coherent policy. Personally I much prefer attribute
>    mechanisms (they're textually denser!), though structured options, such as
>    character maps (!) will require elements, and the options for
>    fn:serialize() are now in the form of elements e.g. <output:serialization-parameters><output:method
>    value="html"> - though they still use a @value attribute!
>
>
> But the largest issue is how to address the use of maps, which is by far
> the most coherent mechanism, enabling content and all properties to be kept
> together.
>
>    1. One objection might have been that the order of entries in a map is
>    undefined (i.e. the return from map:keys()) - this can be accomodated
>    by consistent use of a 'position' property attached to each entry - written
>    when reading from an archive,  used for order (if present) when creating an
>    archive.
>    2. How does the 'element' - based mechanism (used for describing
>    options and properties) co-exist with a map based one? My initial
>    suggestion is that they don't - map-based Archive is in a totally different
>    namespace and uses (almost) ONLY maps. Apart from some probable sharing of
>    implementation code, and being joined at the specification, both have
>    totally separate function catalogs, examples and test suites. [For example
>    arch:to-files() and archM:to-files() would have different internal
>    operational definitions (actually in terms of their use of entries())
>    though their external function would be identical.]
>    3. Maps require some support for XPath3.0 - at the absolute minimum
>    the functions map:entry(), map:new(), map:keys() and map:get()from
>    XSLT3.0 in the absence of the map{} syntax of XPath3.0 - how many
>    implementations will have this?
>    4. I've used the prefix archM: in the spec for all the map-based
>    stuff, but it's a little awkward in reading. Of course you're free to use
>    (almost) any prefix you wish in code, and could re-use arch:, but in
>    practice we tend to stick to the spec.conventional prefix to aid
>    understanding. Any suggestions for a better differentiation between
>    arch: and archM: ?
>
> My suggestion is that we aim in version 1.0 to support both
> element-structure and map-based libraries, but make it clear that
> additional functionality (1.1 etc...) will be focussed almost exclusively
> on using maps.
>
>
>
> Reactions are more than welcome.
> --
> *John Lumley* MA PhD CEng FIEE
> john@saxonica.com
> on behalf of Saxonica Ltd
>



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 EURO