- From: John Lumley <john@saxonica.com>
- Date: Tue, 22 Apr 2014 16:34:10 +0100
- To: public-expath@w3.org
On 22/04/2014 15:51, Christian Grün wrote:
> 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).
As far as I can see the File Module only uses such structure for
serialisation parameters (where of course they should be the same, and
the putative arch:xml() function would use them without change). Is
there somewhere else I've overlooked? My gripe is about the use of
option-name/@value structures, which can look tedious and apparently
have no better representative power than option-name="value", especially
as properties could be 'duplicated'.
> Users will be thankful if they can apply the same rules to as
> many functions and modules as possible.
If so then I suggest that we do not try to be symmetric in our use of
entry descriptions, otherwise we'll have to live with
arch:entries()[ends-with(arch:name/@value,'.xml')] if
arch:entries() returns complete structure,
as opposed to
arch:entries()[ends-with(.,'.xml')] if it returns xs:string*
[I can't see us really wanting a mixed element()/text() representation
such as:
<arch:entry>file1<arch:compression value="flat">..... </arch:entry>
can you?]
Of course the alternative would be to add another layer of convenience
functions....... sigh......
--
*John Lumley* MA PhD CEng FIEE
john@saxonica.com <mailto:john@saxonica.com>
on behalf of Saxonica Ltd
Received on Tuesday, 22 April 2014 15:34:35 UTC