- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Thu, 6 Feb 2014 14:35:11 +0000
- To: John Lumley <john@saxonica.com>
- Cc: EXPath ML <public-expath@w3.org>
On 4 February 2014 10:52, John Lumley wrote:
Hi John,
Thank you for your email!
> Some discussion took place in November and December (with an
> unpublished Editor's draft)
It looks to me like public at least:
http://expath.org/spec/archive/editor
> 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).
> But the largest issue is how to address the use of maps
Yes. To be honest I don't really like the current approach.
I think we should have either (1) only map or only elements, or
(2) one single namespace with a consistent set of functions, like two
different front-ends for the same features (the user can chose either
the map- or element- based versions).
Honestly, I am not a big fan of the not-ordered nature of maps here.
But I guess I can live with it, if there is a "position" property in
entries.
Another point is that, I believe, we are not sure yet which
processor will support maps and when. From the current XSLT LCWD
<http://w3.org/TR/xslt-30/#conformance>, if I understand correctly,
maps will be a required feature of conformant XSLT 3.0 processors.
But we do not know for XQuery 3.1 (nor when XQuery 3.1 will be out,
probably not before a couple of years. Probably time to update the
following table and add a new "map" column? :
http://wiki.expath.org/wiki/Engines#Comparison
Regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
Received on Thursday, 6 February 2014 14:36:02 UTC