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