Hi Marc, thanks for summarizing the Qizx property features.
> - There are system properties that every node has (nature =
> collection|document and path eg. /foo/bar/baz.xml).
In our case, members would probably resources (raw data or xml documents). We could also provide properties for database paths -- as an alternative for collections -- but this would complicate matters as we would need to work with property hierarchies, in which local properties could override more global one, etc.
> Querying on properties is fast, that's what I know (not sure how it is
> worked into indexes so I shouldn't speak about it's implementation :-)
Out of interest: how many documents have you been working with (thousands? millions?).
> Extension functions for property handling (ns xlib):
Interesting to see that there are also some XQuery functions avaliable, so our approach wouldn't differ that much.
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>
Possible signatures:
* db:properties($db as xs:string) as element(resource)
* db:properties($db as xs:string, $path as xs:string) as element(resource)
It would then be possible to search for specific values as follows:
for $prop in db:properties("db")
where $prop/creation-date = '2003-03-03' and
$prop/description contains text "suitable" ftand "purpose"
return $prop/@name/string()
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
A second function could be used to store properties (the path would possibly need to refer to a single resource). The function would be *updating*, i.e., it would be added to the pending update list and executed after the evaluation of the query:
* db:set-property($db as xs:string, $path as xs:string, $key as xs:string, $value as xs:string)
The equivalent BaseX commands could be...
* PROP GET
* PROP GET [path]
* PROP GET [path] [key]
* PROP SET [path] [key] [value]
It would operate on an opened database, and it could be used as follows:
* PROP GET: returns all properties of all resources
* PROP GET path/to: returns all properties of resources in the specified path
* PROP GET "doc 1.xml": returns all properties of a specific resource
* PROP GET file.xml creation-date: returns specific property
Both the database commands and the XQuery functions could be used with the existing APIs.
Suggestions?
Christian