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
