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?


For reference, Alfresco hooks into the ObjectTypeId specified in the  
Atom entry, defaulting to Document, if one is not specified.

That's just our interpretation.

I don't feel that url arguments are the appropriate mechanism.

Dave


On 13 Mar 2009, at 09:32, Florent Guillaume wrote:

> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



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