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