Issue Details (XML | Word | Printable)

Key: CMIS-128
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Al Brown
Reporter: David Caruana
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OASIS Content Management Interoperability Services (CMIS) TC

Query result set AtomPub binding is ambiguous and implies object mapping, not row mapping

Created: 09/Mar/09 07:26 AM   Updated: 11/Jan/10 06:58 PM
Component/s: REST/AtomPub Binding
Affects Version/s: Draft 0.50
Fix Version/s: Draft 0.62

Proposal:
Feed returned is comprised ofatom entries that contain only the cmis property bag. Only the bare minimum atom entry links and fields are required to be set. If the query is non join and an underlying object is identifiable for the property bag, then a repository MAY include a full representation of that atom entry.


 Description  « Hide
The Query response example in part II (AtomPub) implies cmis:object is rendered for documents matching query criteria (there's a comment in the example). This mapping is probably ok for queries without join, as the implication is that objects of a single type are queried.


However, queries with joins don't map well to object oriented result sets.


It seems we're missing a row/col mapping. In fact, this may be the primary mapping (with an optional injected cmis:object, or link to object where applicable).


We may also want to consider including inline query meta-data, or a link to query meta-data.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Al Brown added a comment - 10/Apr/09 05:13 PM
Couldn't you put the selected properties of a join in cmis:object in the atom:entry and create synthetic fields for atom fields? Also the links would have to be removed.

That would be consistent with what is there, just more text in the document is required to explain the behavior.

Ryan McVeigh added a comment - 21/Apr/09 06:30 PM
I agree with Dave that we are missing a row/col mapping. It seems like we're not yet geared towards returning cmis:object's. This gets complicated when using things like the UPPER, SCORE and AS functions - then returned properties won't necessarily match the type's property definition names.

I would like to see the Query specification be explicit about what should be returned. If this is truly a collection of cmis:object's then how is join possible? What about the functions that change property names in the response? Or adds them in, in the case of SCORE?

Assuming the response is a collection of entries, then what does the self link point to?

Al Brown added a comment - 27/Apr/09 01:22 PM
Clarify with the spec, then review with the tc

Al Brown added a comment - 15/Jun/09 01:05 PM
defered to next meeting. al to update

Al Brown added a comment - 29/Jun/09 12:25 PM
accepted

Al Brown added a comment - 01/Jul/09 12:39 AM
Added to 62c:

This document contains the representation of the allowable actions the user may perform on the referenced object.

Al Brown added a comment - 05/Jan/10 12:47 AM
JIRA Cleanup