Re: [cmis] AtomPub: How to deal with type information when creating adocument?

[Al Brown <albertcbrown@us.ibm.com>]

We also leverage the ObjectTypeId to specify which type on creation. That is also a good point on the WS call since it is duplicated in the property bag. Do you want to create an issue removing TypeId from the Create* services?

-Al

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.

David Caruana ---03/13/2009 07:24:01 AM---For reference, Alfresco hooks into the ObjectTypeId specified in the

From:	David Caruana <david.caruana@alfresco.com>
To:	Jens Hübel <jhuebel@opentext.com>
Cc:	cmis@lists.oasis-open.org, Florent Guillaume <fg@nuxeo.com>
Date:	03/13/2009 07:24 AM
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
>


---------------------------------------------------------------------
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