Guido Casper wrote:
Why holding the meta data redundant at all? The meta data is already there (on the WebDAV server, even if not DASL enabled). You just need to find a way to index afterwards.
A SQL DB would be nice to store and index a certain set of predefined properties but it falls short if you have any abitrary user-defined properties (as is the case with WebDAV).
When I first heard about the idea for using Cocoon as a DASL indexing engine I immediately thought about using Lucene for this.
You would need any collection respond to a GET request with a XML representation as the TraversableGenerator generates. The links view applies an additional XSLT stylesheet:
<map:view from-position="TraversableGenerator" name="links"> <map:transform src="2htmlLinks.xsl"/> <map:serialize type="links"/> </map:view>
So the whole WebDAV repository can be crawled by Lucene. And Lucene's content-view-query is configured as "cocoon-view=properties".
with the "properties" view being
<map:view from-position="content" name="properties"> <map:transform type="source-props"/><!--reading props--> <map:serialize type="xml"/> </map:view>
You would need the LuceneXMLIndexer to store ALL fields (instead of just a few configured ones), as a DASL query could request all properties. You could even index content and properties side by side, as DASL may query the content itself.
The challenging part is to create another SearchGenerator that parses the DASL query, although it shouldn't be too hard to at least cover a basic DASL subset.
If all this once is working you can easily DASL-enable any InspectableSource and it fits more nicely with Cocoon's architecture IMHO.
Does this make sense?
Sounds reasonable to me.
I specifically like the fact to be able to query any InspectableSource via DASL.
Guido
Bye, Andreas
