Re: Proposed EXPath module: resource collections

I did it this way because Jonathan Robie had suggested that there might be resources without URIs, or where retrieving the resource via the URI was comparatively inefficient. With this mechanism, fetch() might in some cases almost be a no-op - the result might already be present in the resource map itself.

I'm not sure that being unable to statically determine that fetch() exists as a function name is such a big problem. Javascript seems to cope. And the costs will generally be very small compared with network, file I/O, and parsing costs.

Michael Kay
Saxonica
mike@saxonica.com
+44 (0) 118 946 5893




On 18 Feb 2015, at 13:16, Christian Grün <christian.gruen@gmail.com> wrote:

> 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 14:04:31 UTC