Re: Archive Module -revival

Hi John,

> Note that output:serialization-parameters of course does now use children,
> but i) they use output:option-name/@value for everything except
> ii)output:use-character-maps, which doesn't appear to be needed directly in
> any of the main Archive functions.
>
> [...]
>
> Before going further opinions, and consensus are needed here.

I would propose to stick with the conventions that have been chosen
for fn:serialize. These rules have also been applied to the EXPath
File Module (and, of course, the initial version of the Archive
Module). Users will be thankful if they can apply the same rules to as
many functions and modules as possible.

Christian




 [It may of course appear as an argument
> to the suggested convenience function arch:xml(), which is a compound of
> bin:encode-string(fn:serialize()), but an output:serialization-parameters
> element would be strictly local to that call and not a part of any archive
> entry description.]
>
> A consistent approach would have both entry descriptions the same for input
> and output, so arch:entries() should perhaps yield arch:entry()*, which
> means finding names would involve something like
> arch:entries()[ends-with(arch:name,'.xml')] or even more hideously
> arch:entries()[ends-with(arch:name/@value,'.xml')], which does frankly get a
> bit tedious. But there's no true art without suffering.
>
>
> 2. Map-based functions:
>
> I'm going to suggest that support for all the functions based on
> element-based entry descriptions is mandatory (and thus should be fine for
> XPath2). The functions based on XSLT3.0 map types are optional, but if
> implemented, all must be supported, and that they are i) still in the same
> namespace as the element-based manipulation functions, i.e. Archive now only
> occupies ONE namespace and ii) have a consistent suffix (e.g. '-map' or
> perhaps '-as-map') on the name of the equivalent function.
>
>
> I'm in the mood for modifying the Editors Draft spec now, so opinions would
> be welcome. None of the solutions doesn't have drawbacks or is as elegant as
> we'd like, but we should try to push to get this standard near completion.
> With some consensus on these two issues I can redraft the spec much closer
> to a likely final form. I'm reluctant to start on that redraft (which of
> course involves concurrent changes to test suites and (Saxonica's)
> implementation, for those of you who recall my XMLPrague talk) until I'm
> pretty happy about the first issue in particular, as the map issue is much
> more clear-cut.
>
> John
>
>
> --
> *John Lumley* MA PhD CEng FIEE
> john@saxonica.com <mailto:john@saxonica.com>
>
> on behalf of Saxonica Ltd

Received on Tuesday, 22 April 2014 14:51:57 UTC