Hi Christian,
The amount of files was rather in the thousands than the millions. So yeah, still not "big" data ;-)
I am just thinking loud.. The current output of db:list-details looks as follows:
<resource raw="false" content-type="application/xml" modified-date="2012-02-02T19:13:42.000Z">file.xml</resource>
We could add user-specific properties as attributes, e.g.:
<resource raw="false" content-type="application/xml" modified-date="2012-02-02T19:13:42.000Z" creation-date="2003-03-03">file.xml</resource>
Obviously, the serialized representation of an element could get pretty bulky, and the property names would not be allowed to match existing property names.
Maybe it's better to introduce a new function that returns the following output...
<resource name="/path/to/file.xml"> <creation-date>2003-03-03</creation-date> <description>what a wonderful file</description> </resource>
Attributes with namespaces would be another possibility but this might needlessly complicate things and some are allergic to namespaces ;-)
As one of the possible values (at least for Qizx, not sure if you want to support it for BaseX too) is nodes storing the values in attributes wouldn't be good.
I think your second suggestion is probably best (using separate resource element. Only I think that to avoid confusion with "resource" elements returned by db:list-details(), maybe it's better to call it "properties".
<properties name="/path/to/file.xml"> <creation-date>2003-03-03</creation-date> <description>what a wonderful file</description> </properties>
I would also think that it's worth mirroring the original system "properties" returned by db:list-details. So the return value from db:properties() would be, in fact, a superset of db:list-details(). The system properties being maintained by BaseX and not modifiable by the user.
Returning such an XML structure deviates from Qizx (which is fine of course, only mentioning it) in that Qizx only allows access to properties via accessor functions and through the query expressions inside xlib:query-properties().
I do feel that this is a bit clearer separation of concerns and underlining the meta-ness of these properties. Also may provide better control over access and easier to return a typed value. But I'm not sure as I'm not so familiar with how all this is implemented.
It *could* be that performance of such queries may not be sufficient enough if we deal with lots of lots of resources, but we could introduce some custom query optimizations in a second step. We could also add a function to retrieve a single key (using exact match):
- db:property($db as xs:string, $path as xs:string, $key as xs:string) as
xs:string
Okay, so from this signature I understand that you're not planning on returning different property value types. Is that right? It would be very handy if a date property would return an xs:DateTime instead of just a string and above I more or less assumed similar types as for Qizx. But if you think that's not feasible (now) ...
--Marc