Re: Thoughts on cx:zip

Dave Pawson <dave.pawson@gmail.com> writes:
>> The idea is that the manifest says what to do. The step takes the
>> documents identified by the @href's in the manifest and puts them in
>> the zip file with the names specified by the @name's.
>
> -1, but only if you are considering the idea of XSLT style variables?
> Using indirection via a manifest I lose the ability to list out the
> files using variables which the implementation has resolved?
> How to get dir/dir/*.xml ?
>
> I'm thinking of ant's fileset? Is that too much?

You can do it by transforming the output of p:directory-list into a
manifest, or any other method for generating XML. But I see your
point.

>> If one of the source documents has the same base URI as one of the
>> @href's, then that document gets serialized and stored in the zip.
>> Otherwise, the specified @href gets read and stored.
>>
>> For 'create', the zip file is replaced by the new contents.
>>
>> For 'update' and 'freshen', entries in the zip file not mentioned in
>> the manifest are left unchanged.
>
> update != refresh? Sounds the same?

These are standard zip options. Update replaces all the files in the
zip, freshen only replaces files that are newer than what's already in
the zip.

>> For 'freshen', the entry in the zip file is replaced only if the entry
>> in the manifest is newer (or if the entry will come from the source
>> port, which is always assumed to be newer).
>
> sounds the same as update

Except for the checking the timestamp part :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Many who find the day too long, think
http://nwalsh.com/            | life too short.--Charles Caleb Colton