Re: EXPath Archive: updated specification: Editor's draft 12 May 2014

On 19/05/2014 12:34, Christian Grün wrote:
> I wanted to point out that the output of the
> existing archive:entries() function - with the file paths as text node
> - could already be used as input for new archives. If I see it
> correctly, the archive:entry-names() function only got necessary
> because the paths were now moved to a value attribute. What was the
> main intention behind this change?
As there appeared to be pressure to conform to the standards of 
serialization parameters, which (crazily IMHO) uses elements for 
property names AND an @value attribute to hold the value of that 
property, then it appeared to me that all properties (of which a name is 
merely one, though of some importance) should stick with the same 
convention. Hence arch:entry-names() to give a more user-friendly 
interface. If we retain the file path as a principle text node then we 
get something like:

    <arch:entry><arch:size value="123435"/>folder/file</arch:entry>

which is totally messy, as of course we get the possibility of entries 
having multiple text nodes where order is critical, to say nothing of 
whitespacing.

[Personally my preference, apart from maps of course, is to use 
attributes as properties (avoids duplicates), with occasion structure 
for things like character maps. I was merely following what I perceived 
to be the needs/desires of others....]

John

-- 
*John Lumley* MA PhD CEng FIEE
john@saxonica.com <mailto:john@saxonica.com>
on behalf of Saxonica Ltd