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