- From: Christian Grün <christian.gruen@gmail.com>
- Date: Wed, 18 Feb 2015 14:16:54 +0100
- To: Florent Georges <fgeorges@fgeorges.org>
- Cc: Adam Retter <adam@exist-db.org>, Norman Walsh <ndw@nwalsh.com>, "Robie, Jonathan" <jonathan.robie@emc.com>, Michael Kay <mike@saxonica.com>, Mike Sokolov <msokolov@gmail.com>, EXPath CG <public-expath@w3.org>, Hans-Jürgen Rennau <hrennau@yahoo.de>
Marc proposed that the map returned by rc:resource-collection contains a key "fetch", which has a zero-arity function as value. This function can then be used to retrieve the resource associated with the that map entry. A similar approach has been taken for the XQuery random generator [1], and Michael also proposed such an approach for the SQL Module during our F2F meeting in Prague. Functions that generate new functions can in some way be compared to constructors in object-oriented languages, but the difference (at least for now) is that XQuery <= 3.1 does not allow us to specify what keys and values a map will contain. This means that the second function calls in both of the following XQuery expressions... rc:resource-collection(...)?fetch() rc:resource-collection(...)?whatever() ...can only be evaluated at runtime. As a consequence, a validating XQuery editor will not be able to mark whatever() as invalid. It may be possible to do, however, if we define rc:whatever() as a statically known function. Does this help? Christian [1] http://www.w3.org/TR/xpath-functions-31/#func-random-number-generator On Wed, Feb 18, 2015 at 2:05 PM, Florent Georges <fgeorges@fgeorges.org> wrote: > Makes sense to me. I am not even sure any property should be mandatory. > > Besides describing the "framework for resource properties" (how to get and > set them), the benefit of defining "standard" properties is for > interoperability, to ensure that properties provided by several > implementations use all the same name for the same property. > > About your second paragraph, what do you mean by "functions resulting from > the evaluation of maps" and by "being statically parsed"? > > On 18 Feb 2015 13:43, "Christian Grün" <christian.gruen@gmail.com> wrote: >> >> Good idea! I would also welcome the introduction of such a module. >> >> I also believe that the lowest common subset of document properties in >> different implementations boils down to only a few properties.. if any >> at all (except for the document uri). In my experience, most people >> were asking for such an extension to be able to store and retrieve >> application-defined document properties. The Qizx API provided a >> similar feature for that (see [1], Section 8). A compromise could be >> to have a minimum set of mandatory document properties and an extended >> set of recommended properties. >> >> Talking about the fetch function, I would personally prefer to have a >> static rc:fetch function. As long as we don't have enhanced type >> definitions, as recently motivated by John Snelson, functions >> resulting from the evaluation of maps cannot be statically parsed >> anymore. >> >> [1] http://kiwi.emse.fr/DN/qizx-manual.pdf >> >> >> >> On Tue, Feb 17, 2015 at 10:07 PM, Michael Kay <mike@saxonica.com> wrote: >> > >> >> You might consider adding a "size" property. It's pretty useful >> > >> > yes, that was an oversight in my initial list. >> > >> > Michael Kay >> > Saxonica >> > >> >
Received on Wednesday, 18 February 2015 13:17:42 UTC