- From: Christian Grün <christian.gruen@gmail.com>
- Date: Thu, 6 Feb 2014 16:35:16 +0100
- To: John Lumley <john@saxonica.com>
- Cc: EXPath ML <public-expath@w3.org>
Hi John,
finally some feedback:
Personally, I agree with Florent. I like maps very much - but I also
have my doubts if they should be made mandatory in EXPath Modules. I
am not sure, but ut may well be that not all XPath processors will
support maps in future, and we could lose potential users by asking
for too much?
One way out could be to provide two specifications and see which one
will eventually be adopted (but this sounds like additional work and
may cause confusion).
arch:create(
('mimetype', 'META-INF/container.xml', ...),
(arch:text($mimetype), arch:xml($container), ...))
What about supporting both xs:string and xs:base64Binary as input?
> 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</ ..
This may be something that should be standardized outside the Archive
Module. In BaseX, we have at least 10 modules with options as
arguments. We first based our solution on the W3 fn:serialize
function, which expects all values to be specified as attributes.
Later on, we added support for maps, as the syntax is much more
compact.
> One objection might have been that the order of entries in a map is
> undefined (i.e. the return from map:keys())
As far as I know, order should be irrelevant in archive files (at
least in ZIP archives).
What do others think about maps vs. no maps?
Christian
Received on Thursday, 6 February 2014 15:36:02 UTC