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

Hi John,

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

I see; I wrongly thought that with "serialization-like" you meant to
say that elements without text nodes are better serializable in some
way.

As far as I got it (other comments are welcome), the discussion
focused on the syntax of optional function arguments with unique keys
(as element names) and values. Maps could as well be used for this,
and would serve perfectly well, because their keys are always unique.
In the new Archive proposal, however, all keys have the same name
(namely, "name").

In the original proposal (as you indicated in the arising issue
paragraph), the element notation could be used to specify additional
parameters, such as the compression ratio for single files. It would
be great to have this feature readded.

Christian



> 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
> on behalf of Saxonica Ltd

Received on Monday, 19 May 2014 12:09:25 UTC