[OASIS Issue Tracker] Commented: (CMIS-183) Document thumbnailproposal

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CMIS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10651#action_10651 ] 

David Caruana commented on CMIS-183:
------------------------------------

Thank you for the comments. As expected, it's the domain model mapping that's attracted most attention.

The original proposal attempts to keep within the capabilities of the existing domain model, in particular, the retrieval of thumbnail content via getContentStream(). CMIS doesn't support multiple content streams per document (at this time), which may be the ideal solution, and the idea of using a URI property was thought to be binding specific.

> Where is the "location" of these previews?

Good question, and is an issue that I have left to the side for the moment, to get initial feedback on general approach.

> Are we worried about different repositories allowing these previews to be create-able/write-able?

The intent is that repositories create thumbnails, clients only read them. The "preview" relationship type is not creatable, should not be updatable. The preview document also should not be updatable or deletable (as described by allowable actions - note: this needs to be added to the relationship proposal for clarification).

> The current model doesn't really specify how an application should figure out which preview is the default/"best' one for a simple thumbnail-based view of documents in a folder?

The intent is that the specification provides guidance for what is a small, medium and large preview (as identified by the preview label property on the relationship, which has open choice of small, medium and large). It is not required that an implementation provide all of them, or indeed provide them for all documents.

> Related to the previous issue, I'd almost prefer it if we had a separate notion of "thumbnail" vs. "preview".

I would definitely agree, if we agree the requirement is to only support at most one thumbnail per document. If so, I also like the suggested two tiered approach.

> with respect to height & width i think we should probably specify that this is in pixels as a unit, and that we are probably thinking of bitmapped images, right?

Yes, and yes.

> I'd like to remove the preview relationship type and express as a service (getPreviews) that returns an XML structure with the information

I like the idea of encapsulating the "association" between document and preview behind a service call, however, I still think there needs to be a definition in the domain model of what is returned by the service. Is it a new structure such as allowable actions?

> I would add in a notion of icon at the type and object level

That's an interesting one which I haven't captured in the requirements. I think it's a slightly different use case, but related. I would imagine this is an optional provider capability.


I'm not tied to the Relationship Type proposal and am happy it's sparked conversation. In fact, we now have three data model proposals to consider:

1 - "Preview" relationship type (as originally proposed)
2 - Additional Read-only properties on Document i.e. URL, mimetype, height, width
3 - Additional getPreviews() service

In summary, option 1 is most complicated model, and needs deeper definition to ensure no ambiguities, but has potential for expansion in future, as well as fitting with current domain model. Also, not all implementations may find it easy to map to.

Option 2 is the simplest, relies on HTTP GET for thumbnail content retrieval.

Option 3 provides near equivalent model of option 1, but without dictating implementation approach (so may be easier to implement). Requires new data structure to be defined in data model (to represent preview), and as with option 2, relies on HTTP GET for thumbnail content retrieval.

I think the next step is to revisit the requirements listed in the proposal. Some of them may not be required, and this will help chose an option. 

> Document thumbnail proposal
> ---------------------------
>
>                 Key: CMIS-183
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-183
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: New Feature
>          Components: Domain Model, REST/AtomPub Binding, Web Services Binding
>            Reporter: David Caruana
>            Assignee: Ethan Gur-esh
>
> A proposal for allowing a client to retrieve previews (e.g. thumbnail) of a document via the CMIS bindings.
> http://www.oasis-open.org/committees/download.php/32477/document_preview_proposal_v0.2.txt

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira