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: Re: [cmis] AtomPub: How to deal with type information when creating a document?


Hi Jens,

Speaking for AtomPub: passing the typeId as an out-of-band parameter  
is redundant given that objectTypeId is a natural place for it.

This also applies to the SOAP bindings, so I'm not sure why the typeId  
parameter is there for SOAP. Or in the domain model for that matter.

And yes, I think that defining additional parameters to tack at the  
end of URLs would not be very RESTish.

Florent


On 13 Mar 2009, at 09:56, Jens Hübel wrote:

> Hi,
>
> on creation of a document we always need to provide at least: a  
> repository id, a type and a folder plus properties and content.
>
> In the SOAP binding these are parameters of the service method. In  
> the AtomPub binding repository id and folder are part of the URI.  
> But how do I pass the type? The only way I could find is to provide  
> this information in the properties as system property ObjectTypeId   
> (see example: Example-DocumentEntry.xml):
>
> <cmis:propertyString cmis:name="objectTypeId"  
> cmis:propertyType="String">
>    <cmis:value>email</cmis:value>
> </cmis:propertyString>
>
> I have some questions around this…
> 1)      Did I get the spec right in this regard?
> 2)      Do all currently existing REST bindings behave like this  
> (please reply if you do this differently)?
> 3)      If the answer for 1) and 2) is yes then this looks to me  
> like an asymmetry between the Atom and the SOAP binding. We would  
> have two different ways to pass the same information. Shouldn't  
> parameters in a WS method of the SOAP binding be coded in the URI in  
> the Atom binding (e.g. sth. like http://www.cmis.org/rep1/folder4711/...?type=email) 
> . I understand that this approach would have some issues as well. So  
> you can't simply provide the URI in the link of an atom entry, you  
> would need some kind of URI template instead. But passing parameters  
> of a call sometimes in the URL path and sometimes in properties  
> seems not to be so nice (this prevents/complicates having common  
> code between REST and SOAP to parse the properties). I don't have  
> much experience with AtomPub and with REST protocols in general but  
> would a CMIS spec defining addition parameters to be appended to the  
> URI provided in the Atom link entry violate the Atom spec or make  
> this unusual behavior or "a bad web citizen"? Of course we also  
> could change the SOAP binding and pass the type as property  there  
> as well.
>
> Probably this is not restricted  to type and createDocument, but a  
> more general issue: Do we want to have a defined way how parameters  
> of methods in the SOAP binding are mapped to the Atom protocol.
>
> It also would be helpful for an implementor to extend our samples so  
> that they differentiate between read and write operations (have  
> Example-getDocumentEntry.xml and Example-postDocumentEntry.xml). I  
> will suggest this in a JIRA.
>
> Thanks for further clarification
> Jens
>

-- 
Florent Guillaume, Head of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87



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