|
The atom format already supplies an immutable identifier, atom:id. This *can* be an HTTP URL. Alternatively, CMIS could define a method to map the atom:id to a URL.
Related: Cool URIs Do Not Change (<http://www.w3.org/Provider/Style/URI>). So servers that expose known-to-be-unstable URLs are doing the wrong thing in the first place. The options I see are:
1. add uri bases in cmis-specific schema. e.g., <getobject mimetype='application/atom+xml'>http://foo/atomentry</getobject> 2. leverage uri templates http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.txt 3. leverage wadl https://wadl.dev.java.net/#spec #1 is the least standard but probably the easiest/simplist. #2 does not have an xsd format so we would have to create one #3 seems like overkill With URI templates and collections in the workspace element we would have two concepts addressing a similar idea. Shouldn't we focus on one?
How do you propose collections address this? I see two ways - a) define new cmis collection types that take uri arguments as input b) overload an existing collection with different uri arguments that if provided the collection returns a different object on get.
a) this method may introduce collections that do not act as atompub collections. we could turn off post by specifying an empty app:accept. Would we be limited to returning feeds instead of other formats such as atom entry since collections usually return a feed on get? b) we could get probably get away with this, but the behavior of a selected collection would vary between a get without arguments and a get with uri arguments (could be an atom entry for example). These collections would be overloaded which leads to complexity. Based on what I thought of, a new extension to atompub in the workspace was more straightforward. Which of the above (or something else) are you proposing for 168, 169, 170? I'd be happy for collections to provide this functionality and close those issues. b) seems to be the worst solution.
If I'm looking at it from a lazy client developer perspective I already have code that deals with collections. The types and changes collections are also collections that don't accept POST. The main difference would be that this new collection would return a feed with only one entry. I understand that the template mechanism is the cleaner approach, though. If we would introduce it here would it make sense to replace the GET-only collections as well with templates? I can imagine passing a type id the same way. Additionally, if we add folderbypath here we would need an equivalent in the SOAP binding. BTW,
James Snell is proposing an atom i-d to incorporate uri templates. I suggested to him that we would like to use it in the workspace element in the service document. He originally proposed it as a link template in feeds. Only the types and changes collection springs to mind as GET only. Query - post for new queries; Unfiled - POST to unfile from all folders; folder - POST to create, Checkedout - POST to check out a doc. If we want to move away from REST'ish a bit, we could leverage GET in non-idempotent situations for checkout and unfile with uri templates. It's a question of how pure-ish we want to be wrt REST. uri template - http://tools.ietf.org/html/draft-gregorio-uritemplate-02 link template - http://www.imc.org/atom-syntax/mail-archive/msg20170.html Agreed on folderbypath. Added to 62b and example service doc - excerpt:
<cmisra:uritemplate> <cmisra:template>http://cmisexample.oasis-open.org/rep1/entrybyid/{id}</cmisra:template> <cmisra:type>entrybyid</cmisra:type> <cmisra:mediatype>application/atom+xml;type=entry</cmisra:mediatype> </cmisra:uritemplate> <cmisra:uritemplate> <cmisra:template>http://cmisexample.oasis-open.org/rep1/folderbypath/{path}</cmisra:template> <cmisra:type>folderbypath</cmisra:type> <cmisra:mediatype>application/atom+xml;type=entry</cmisra:mediatype> </cmisra:uritemplate> <cmisra:uritemplate> <cmisra:template>http://cmisexample.oasis-open.org/rep1/query?q={path}&searchAllVersions={searchAllVersions}&maxItems={maxItems}&skipCount={skipCount}</cmisra:template> <cmisra:type>query</cmisra:type> <cmisra:mediatype>application/atom+xml;type=entry</cmisra:mediatype> </cmisra:uritemplate> |
|||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
URL to id mapping
An application uses Atom binding to a CMIS repository. It uses CMIS to attach documents and content to its internal business objects. Using Atom everything is based on URLs. There is no generic way to get the id. The application should not store the URI as it contains volatile information like host names, some parameters or even a token. The preferred way would be a standardized way to get the id from the Atom URI, just store the id in the business object attachment and later at retrieval time have a method to convert the id back to a URI pointing the Atom entry.
A second notable area of use. For a generic CMIS client implementing both (SOAP and Atom) bindings it would be much easier to encapsulate the binding specific logic from the common parts if it just needs to deal with ids.