OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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

Ethan Gur-esh commented on CMIS-183:
------------------------------------

This is a great start. But I have a few questions/feedback issues about this proposal:

1) Do we really want to have thumbnails as separate documents? I like that this model allows for an arbitrary set of previews (and that it allows for theoretical extensibility for multiple sets of properties), but it also introduces some potential weirdness into the domain model that we need to consider, including:

- Where is the "location" of these previews? Are we expecting that they will show up in the same folder as the Documents? Are we thinking that they will NOT show up via getChildren calls? MAY show up in getChildren calls? (E.g. will there be an optional capability like the "previousVersionsFileable" model we did for previous versions of documents?)
- Are we worried about different repositories allowing these previews to be create-able/write-able? Or do we intend that only repositories will be writing these previews, and applications will only be reading them? (The current model leaves a lot of room for different repositories to expose different semantics here.)

2) 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. (E.g. for the use case of building a thumbnail-style library view like SharePoint does today). We'd need to take a position here (e.g. is it just the "first" thumbnail that is returned in the response to the "getRelationships" method?) 

3) Related to the previous issue, I'd almost prefer it if we had a separate notion of "thumbnail" vs. "preview". E.g.:
-  The "thumbnail"  is an image preview of the document that is expected to be relatively small for use in list views, and is really easy to find -- e.g. maybe it's just a few read-only properties added  to the Document base type, i.e. URL, mimetype, height, width. 
- Documents can have an arbitrary set of additional "previews", as described in this proposal. And these could be multiple down-level renditions of an item (e.g. multiple sizes of an image file, multiple TIF "pages" of a CAD document), which may have additional metadata, etc.

> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]