CMIS VI: A case of unpredictable relations

In CMIS AtomPub extensions, an entry may optionally specify two relations:

1. If this is a folder entry, it only specifies children link if it actually has children
2. 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 folder is empty, i.e., has no children. How can I find out the URL to which I can POST an entry to create a document? Ideally, this should be solved in the manner proposed by hierarchy-ID where a link with rel="detail" is automatically created for folder type of entries. Thereby, if a folder is empty, its detail link would produce a feed with no entries, but include enough information to describe that the collection that produced the feed, i.e., the folder resource, is willing to receive new entries and the URL at which a POST request will result in a new document entry being added to the folder would also be disclosed. Here's what I mean in terms of concrete syntax:

<entry>

  <title>Folder metadata</title>


  <link rel="self" href="/a;metadata"/>

  <link rel="edit" href="/a;metadata"/>

  <link rel="children" href="/a/" title="document children collection"/>

  <id>tag:example.org;2009:1</id>

  ...

</entry>




<feed>

  <title>Folder contents</title>


  <link rel="self" href="/a/"/>

  <link rel="parent" href="/a;metadata"/>

  <id>tag:example.org;2009:1-1</id>

  ...

  <app:collection href="/a/">

    <title>Folder collection</title>

  </app:collection>

</feed>


This mechanism works in all cases (for parent and children relations), is auto-discoverable and hence works beautifully with standard AtomPub clients.

One thing to notice here is that I am using a link to the parent folder entry from the folder children feed. Since CMIS allows the possibility that an implementation may or may not allow multiple parents, the optimization for a single parent system is that the parent link returns an entry as opposed to a feed with a single parent entry. This makes it possible for a client to know that it cannot create more parents. 

On a related note, I found that the parent link is optional for document entries. What does it mean for a document to not have a parent? It sounds like another major headache for clients (especially those who are synchronizing for disconnected use) to know under what conditions certain entries will outlive their parent folders.