Re: Archive Module -revival

Time to get back on the the EXPath Archive module. Some resolution on 
two representation issues is required:

1. Archive/entry options as XML element trees:

     On 06/02/2014 14:35, Florent Georges wrote:
>> Whether options for an archive should be read or set through
>> >attributes on an element, or child elements
>    I would tend to prefer child elements, as you don't end up been
> stuck with atomic values (in attributes) if some options should be
> structured (as you can have with elements).
>
I'm looking at the Archive module again and am trying to decide whether 
to propose for the XML-tree entry descriptions, to use ONLY child 
elements and text values and abandon attributes. E.g.:

     <arch:entry>
         <arch:name>file1</arch:name>
         <arch:compression>flat</arch:compression>
         ...
     </arch:entry>

rather than
     <arch:entry compression="flat">file1</arch:entry>

or
     <arch:entry>
         <arch:name value="file1"/>
         <arch:compression value="flat"/>
         ...
     </arch:entry>

Personally I prefer denser attribute systems (which have the advantage 
that the names are not duplicated), but understand the possibility of 
child-structured elements (e.g. character maps) - but thus far none of 
the functions have needed such capability.

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. [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.

Before going further opinions, and consensus are needed here.


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:32:12 UTC