W3C home > Mailing lists > Public > public-expath@w3.org > February 2015

Re: Proposed EXPath module: resource collections

From: Hans-Juergen Rennau <hrennau@yahoo.de>
Date: Fri, 20 Feb 2015 14:00:23 +0000 (UTC)
To: Michael Kay <mike@saxonica.com>
Cc: "jonathan.robie@emc.com" <jonathan.robie@emc.com>, "ndw@nwalsh.com" <ndw@nwalsh.com>, "christian.gruen@gmail.com" <christian.gruen@gmail.com>, "public-expath@w3.org" <public-expath@w3.org>, "msokolov@gmail.com" <msokolov@gmail.com>
Message-ID: <1338123949.4783030.1424440823307.JavaMail.yahoo@mail.yahoo.com>
You wrote: "I'm not aiming for portability at that level. If it's needed, it can be layered on top. For example, I can envisage a separate spec for SQL-collections that describes how to map collections to SQL databases, and what kind of properties such a collection exposes."
Very well, let us put portability out of scope. But still I have no clue how to map collections of resource descriptors to persistent artifacts without a scheme, if efficiency is important.
Hans-Juergen
(posting repeated due to a technical problem affecting the original posting)
      


 

     Michael Kay <mike@saxonica.com> schrieb am 11:40 Freitag, 20.Februar 2015:
   

 I'm not aiming for portability at that level. If it's needed, it can be layered on top. For example, I can envisage a separate spec for SQL-collections that describes how to map collections to SQL databases, and what kind of properties such a collection exposes.
Michael KaySaxonicamike@saxonica.com+44 (0) 118 946 5893



On 20 Feb 2015, at 09:38, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

You wrote: "Are you thinking here of some kind of concept of collection-type, where the properties of a collection depend on its collection-type, and there is some kind of schema for a collection-type to show what properties are available?"
Yes, exactly. Now let me ask you: if we do not have some simple scheme, how to translate the resource descriptors into persistent artifacts expressing their information content, e.g. relational tables? A scheme can be mapped to a table schema in a generic way. Without scheme - how to proceed, and in particular how to proceed efficiently? (A generic representation, with rows containing two columns for property name and value item, respectively, would be feasible, but very inefficient.) And how to proceed in a portable way, so that one XQuery processor might produce (a persistent representation of) a set of resource descriptors, and another XQuery processor apply a filtering to it? This would be enabled by a scheme and generic sets of mapping rules (scheme -> artifacts). How to proceed without a scheme?

Hans-Juergen
 

     Michael Kay <mike@saxonica.com> schrieb am 9:37 Freitag, 20.Februar 2015:
   

 > 
> For me, there remains one major open question - how to express collection-specific models of resource descriptors, and I suggest the following requirements:
> 
> * an artifact which is accessible to the XQuery user
> * a format which is platform and XQuery processor independent
> 
> Advantages: the user can himself design and manage the collections (if appropriate API functions are provided); portability across XQuery processors.
> 
> How about a little XML vocabulary? Alternatives? Would you expect it to be hard to agree upon the details?
> 

Are you thinking here of some kind of concept of collection-type, where the properties of a collection depend on its collection-type, and there is some kind of schema for a collection-type to show what properties are available?

I was thinking of something much simpler, where each collection can have different properties, and indeed there might be different properties available for different resources within a collection (for example, directories within a directory have different property-sets than files within the same directory); users either know what properties to expect for a given collection URI, or find out what is available by using map:keys().

Michael Kay
Saxonica


    



   
Received on Friday, 20 February 2015 14:01:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:39 UTC