Fixed Hans-Juergen email address... On 18 Feb 2015 14:05, "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:09:16 UTC