AtomPub Archive

Discovering AtomPub Collections – best current practices

When working with data synchronization using Atom feeds in AtomDB, we frequently encounter situations where we learn about a feed simply through its public URL. However, most feed documents do not provide any indication of whether new items can be added to them. (This is not because of a lack of existing standards but because

CMIS X: Is CMIS a good AtomPub citizen?

CMIS has consumed a lot of my blog space for a good reason. Hierarchy is quite important to CMIS and we (Colm Divilly and I) have spent a great deal of time on it. Despite having pointed out several issues in this blog, I can’t beat the feeling that CMIS is determined to go its own

CMIS V: Semantics of multi-parent document entries

First a disclaimer: I haven’t read the CMIS domain model completely, but I think I understand the premise broadly. CMIS allows a document to be hard-linked from several folders. Therefore the same document entry may occur in several folder children feeds. The CMIS AtomPub extension spec does not clarify whether the entry occurring in different

CMIS I: AtomPub binding and AtomPub service documents

This is the beginning of a new series of posts on the still-nascent AtomPub binding of CMIS. Although, this spec has been seen by over 20 companies (led by IBM, Microsoft, and EMC that are participating in its TC) over six months now, I doubt anyone involved in writing this spec has ever written an

CMIS II: (C)MISsing good old AtomPub

In my earlier post on AtomPub vs. CMIS, I expressed concern that new constraints on Atom syntax introduced by CMIS go so far as to rule out using a standard AtomPub client with a CMIS AtomPub server. In theory, one could say that adding a new required element to Atom’s schema is a non-starter. However,

CMIS VII: has more items and paging

In the example for folder children included with the AtomPub bindings for CMIS, I noticed a weird thing just before the end of the document:     …   </ns3:entry>   <ns1:hasMoreItems>false</ns1:hasMoreItems> </ns3:feed> Now Atom’s liberal content model allows various kinds of foreign markup. However, Atom very carefully prevents any foreign markup from occurring at the end of

CMIS VI: A case of unpredictable relations

In CMIS AtomPub extensions, an entry may optionally specify two relations: If this is a folder entry, it only specifies children link if it actually has children If this is a folder or document entry, it only specifies parent link if a parent exists. There is a basic problem with this approach. Suppose that a

CMIS III: Gratuitous CMIS markup on Atom elements

I never quite understood the need to enlist the help of cmis:id on atom:link elements, which is called for in Section 3.2 of AtomPub bindings for CMIS. There are prominent signals about its importance, but no justification of its needs in AtomPub link relations. For example, here’s what a atom:link element would look like if

CMIS IV: Confusing feeds and collections

CMIS AtomPub extension does not see any difference between feeds and collections, even though they are vastly different in Atom’s data model. A feed is a representation of a resource whereas a collection is a resource and it defines the methods (and its semantics) and representations that can be exchanged with it. CMIS provides a

CMIS IX: Confused loyalties – CMIS or AtomPub

In a previous post, I complained that I miss good old AtomPub when working with CMIS servers. One of the reasons is duplication of key information items of Atom in a CMIS property set. One of my colleagues reported an issue to the CMIS TC for CMIS properties that duplicate APP/ATOM information. Duplication produces two problems