Document Management : Allow DAV API Clients to specify non-root parent collection.

Hi,

Fixing a small bug caused by a conflict between File Server and File Relation Server made me dream again about what I first dreamt about when I tried File Server. Imagine! No more dictatorship of the hierarchical folder structure! Multi-parent taxonomies, graph-like access to files... Very inspiring :) Here's maybe one way to go down this route.

It seems that with the DAV API the proper way to implement File Relation Server and File Server functionalities would be to have some separation of concerns and different WebDAV browsing modules (DAV API Clients) based on for instance:
- node type (as with File Relations Server now)
- og (as with File Relations Server now)
- file type (as with File Relations Server now)
- RDF Relations (as with File Relations Server now)
- taxonomy (as with File Server currently)
- by year/month/day
- by author name
- for pictures how about exif data sorting or even a fancy face recognition feature (wouldn't it be nice?)
- imap browsing

You would then be able to define where these clients would be made available in the directory structure :
- Vocabulary 1 <- Root Collection (Could have other root collections beside it)
- Term 1
- OG 1 <- OG DAV Module setting : Parent -> Root Collection + w Depth of 1
- Month 1 <- Date DAV : Parent -> OG + Depth 0
- Month 2
- Term 1 from Vocabulary 2 <- Taxonomy DAV : Parent -> Date DAV + Depth 0
- Term 2 from Vocabulary 2

This would allow dynamic directory structures:
- Communication Department
- Web advertising campaigns
- Drupal Con 2020
- February 2020
- March 2020
- Invoices
- Analytics

The og_vocab feature of File Relation Server would then "simply" emerge from this, by mapping an OG DAV as parent of a Taxonomy DAV collection.

You could then have several mappings for different departments, for instance allowing the accounting department to see only invoices categorized by supplier or projects.

How about it?

Best,

Jun