Re: EXPath Archive: updated specification: Editor's draft 12 May 2014

Hi John,

this may be late, but I wanted to point out that the output of the
existing archive:entries() function - with the file paths as text node
- could already be used as input for new archives. If I see it
correctly, the archive:entry-names() function only got necessary
because the paths were now moved to a value attribute. What was the
main intention behind this change?

Best,
Christian


On Mon, May 19, 2014 at 12:59 PM, John Lumley <john@saxonica.com> wrote:
> An updated editor's draft of this specification (12 May 2014) is available
> from:
>
> http://expath.org/spec/archive/editor
>
> (A diff version from the previous (3 December 2013) version is available but
> not yet on the website). The major changes are:
>
> Shifting to a fully serialization-like structured entry description, e.g.
> <arch:entry><arch:name value="picture.jpg"/>.....
> Map-based functions are an optional interface, in the same namespace as the
> element-based versions and with '-map' suffix to the name.
> Map-based functions can use 'position' properties to report on and control
> archive order.
> All map-based functions use single maps, rather than map sequences, as
> arguments.
> A new function arch:entry-names() just yields the names of all the entries
> in sequence (simpler than the structured one, and useful when using maps.)
> Two convenience functions arch:text() and arch:xml() are defined, to
> generate xs:base64Binary for archive content sequences.
>
> Issue(s) arising:
>
> I have not yet used structured entry descriptions in arch:create() and
> arch:update() - to do so would require polymorphism (i.e. type detection) on
> the arguments, as the arity would probably remain the same between
> structured entry and string versions. To create with different compressions
> on a per-entry basis (as might be needed for EPUB) would require something
> like this. The alternative is to use different function names for the two
> versions. [On the other hand you could be modern and use maps, where you can
> do this as easily as falling off a log....]
>
> Further work:
>
> Some of the examples need further alteration; minor formatting changes
> I have not yet started changing the qt3 tests on GitHub (or indeed our Saxon
> implementation) until the shift to structured entry descriptions is pretty
> clear.
>
> Reactions would be welcome. I hope that with the specification as now
> altered, we can move to some reasonably quick convergence and actually get
> this specification completed.
>
>
>
> John Lumley
> --
> John Lumley MA PhD CEng FIEE
> john@saxonica.com
> on behalf of Saxonica Ltd

Received on Monday, 19 May 2014 11:35:32 UTC