Custom Query (900 matches)

MDRepository has to list the hierarchy of available collections.

Collections are defined as MD-records linking to other MD-records (think 'folder'), thus the hierarchy is constituted by linking in: ResourceProxy[ResourceType='Metadata']:

<ResourceProxy id="d71803e14">
  <ResourceType>Metadata</ResourceType> 
  <ResourceRef>../dobes_data/Corpusstructure/dobes.imdi.cmdi</ResourceRef>         
</ResourceProxy>

The link (ResourceRef) being a path to appropriate MD-records in the data. In the current test-data set the collection-MD-records are in the respective Corpusstructure folders.

So MDRepository needs to build up an index (tree) of this structure (as it seems way to expensive and unnecessary to traverse the hierarchy on every request) and provide this on the agreed upon interface:

 ?operation=getCollections&collection={collection-path}[&maxdepth={number}]

Here is a proposal of the XML-structure: source:MDService2/trunk/MDService2/testdata/collections_extract_lv3.xml​ There is unfortunately no schema for that yet, but it is also subject for discussions. However this proposal is newer (=?better) than ​what MDRepository currently offers on that interface. In any case we need the hierarchical structure reflected in the xml and the counts.

MDService currently serves it's own static snapshot of the collection-tree, derived directly from the folder-structure! This is just a temporary workaround. Although the collection-hierarchy is to large extent parallel to the folder-structure in the test-dataset, the correct way is clearly defined and there we need to go.

It should be yet discussed how to arrange the top level. One sensible option seems to put every provider as a separate top-level-node.

(This probably should find way into the documentation as well.)

MDRepository shall provide statistics about values used in individual elements, on the queryModel interface (as it already does for child-elements), as described in CmdiMetadataServices#queryModel. This also collection-based.

In the result of a query MDRepository sends back the whole MDRecords. MDService translates the whole Resultset two some condensed view (tabular, list), linking two the detail-view for individual MDRecords. However currently actuating this link requires MDService to ask MDRepository for the individual MD-record by means of the MD record identifier: MDSelfLink, although it actually has the required data in it's own cache. It just isn't able to locate the right dataset and to pick the right record out of it.. The task is to implement an index of the cache, which assigns the resultsets with unique identifiers, that can be employed in the resultset view as back-reference to the cached data, which would be carried by the link to the MDRecord-detailview.