Re: Archive Module -revival

On 6 February 2014 15:35, Christian Grün wrote:

  Hi Christian,

> One way out could be to provide two specifications and see which one
> will eventually be adopted

  I would rather not do this.  We have enough work with one spec,
don't we? :-)  I think this phase of the editorial process is the
opportunity for people to speak up.  Giving them the opportunity to
wait untill modules are implemented will probably not help.

>> arch:text($mimetype)

> What about supporting both xs:string and xs:base64Binary as input?

  You then have to define the default encoding for strings.  Which it
possible, the most obvious choice being UTF-8.  But you need to
provide a way to set another one.  arch:text($content, 'ISO-8859-1')
looks like a nice possibility to me.  And it allows more checks and
avoids more errors, which is a good thing (a common gotcha with two
parameters to represent a list of pairs is when one key or one value
is the empty sequence by mistake, which is really hard to catch, while
arch:text() can ensure it does not return the empty sequence).

> As far as I know, order should be irrelevant in archive files (at
> least in ZIP archives).

  The OCF spec[1] (the ePUB spec that defines how to package files
together in a ZIP file) mandates the first entry to be "mimetype"
entry, uncompressed, and containing "application/epub+zip".  This is
an easy way to check this is actually intended to be an actual ePPUB
file encoded as ZIP, without having to unzip the file (a bit like
magic numbers in image files).

  I think that generating ePUB files is an important use case.

> What do others think about maps vs. no maps?

  I'd like to know as well :-)

  Thanks for your comments!  Regards,

-- 
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

[1]http://idpf.org/epub/30/spec/epub30-ocf.html#sec-zip-container-mime

Received on Thursday, 6 February 2014 19:09:17 UTC