Actually I'm not sure why one would want in CMIS/AtomPub to compare
types using URIs, given that:
- a type entry has a cmis:typeId element,
- an object entry has a <cmis:propertyId cmis:name="ObjectTypeId">
and a type comparison can be done using those.
URIs give access to the resource but they're not guaranteed to be
unique (the AtomPub spec mentions, in some other context, the
possibility of have a content URI that points to a cached version of a
media, whereas the edit-media link would point to another).
If you really want a URI for the entry (and in your other
application), then yes "self" makes much more sense that
"alternate" ("alternate" being also the semantics of a link without
On 12 Mar 2009, at 02:22, Shane wrote:
> I realize we another group but I just wanted to close this discussion
> instead of starting a new one, and I am checking in some code soon.
> Are you guys going to settle on <link rel="self" href="..." /> for
> identify the documentType via URI?
> At first I considered "alternate" because I am working on an ATOM
> application myself and ran into the same situation where I have no
> <content />, but I wanted to provide a URI for the entry. I'm now
> thinking that "self" makes the most sense.
> I'm also checking in logging ;)
> On Mar 9, 7:05 pm, Florent Guillaume <florent.guilla...@gmail.com>
>> Ok, success!
>> I can now list folders and documents.
>> Tomorrow I'll deal with content streams.
>> On 10 Mar 2009, at 00:26, Shane wrote:
>>> Good deal.
>>> Are these unfiled documents then? I need to make some changes to
>>> support that. It doesn't show any documents at the 'root' level. It
>>> will only show documents within any of the 'root' level folders and
>>> the child folders.
>>> I was thinking the same thing about logging. I usually add some
>>> tracing when I am debugging, but I haven't actually thought about
>>> logging out to a file yet. I'll look into that.