[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AtomPub: How to deal with type information when creating a document?
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]