[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (CMIS-135) createDocument & checkIn- Accept an optional contentStream input. How is this included and encoded?
[ http://tools.oasis-open.org/issues/browse/CMIS-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Al Brown updated CMIS-135:
--------------------------
Proposal:
In light of the atomic create/update issue, we should probably keep the stream as input to these two methods.
was:
Option 1) In light of the atomic create/update issue, we should probably keep the stream as input to these two methods.
1b) Clarify how the stream is to be transmitted to the service (this may belong in the binding sections?) If it is encoded in the Entry document xml, clarify how that is to be accomplished (probably by fixing the schema).
1c) Maybe make an optional parameter to getProperty (et. al.) to retrieve an encoded stream? (for symmetry with the create methods)
Option 2) Remove the stream parameter and clarify the process for using setContentStream service in conjunction with createDocument and checkIn.
> createDocument & checkIn - Accept an optional contentStream input. How is this included and encoded?
> ----------------------------------------------------------------------------------------------------
>
> Key: CMIS-135
> URL: http://tools.oasis-open.org/issues/browse/CMIS-135
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: Bug
> Components: Domain Model, REST/AtomPub Binding
> Affects Versions: Draft 0.60
> Reporter: Ryan McVeigh
> Assignee: Ethan Gur-esh
> Priority: Critical
> Fix For: Draft 0.62
>
>
> Sections: 3.4.1 & 3.7.3
> 1) Is this really necessary, as there is an entire set of stream services?
> 2) The schema (CMIS-Core) includes a type (cmisContentStreamType) but it is not referenced anywhere else except in CMIS-Messaging (which appears to be SOAP-related). How might this stream be incorporated into an Atom Entry (for REST) - is it Multi-Part?
> 3) It seems reasonable that a stream be provided to aid in atomic creates/updates.
> 4) If streams really are expected to be large enough to merit a sub-range requirement on getContentStream (see 3.4.7), then is it realistic to expect that one would base64 encode such a beast?
> 5) If the Entry document schema is modified to accept an encoded stream (or the spec clarified as to where this is placed within the Entry), then why would that stream also not be available from getProperties? This leads to an asymmetrical usage of streams.
> 6) For large streams where encoding is not practical, there should be a way to (for example) create a document which requires a stream, set that stream in a separate operation, and then commit/checkin that change (at which time the "required stream" is enforced).
--
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]