[oslc-core] Attachments

[Martin Nally]

I thought some more about attachments in the shower.

The design I still like the best is Dave's non-design, that says
attachments are not a special concept - they are just regular resources,
related to their "attachee" by a regular predicate.

If you really wanted to have something special for attachments, you could
do a design like the one Jim seemed to push on. In this design, attachments
are still resources, but they can only be created by posting to a special
attachee-specific factory, can only be unattached by deleting them, and are
deleted when the attachee is deleted. There is a predicate that links
attachees to attachments, but it cannot be manipulated like a regular
predicate - it can only be altered by new POSTs to the special factory, or
deletes of existing attachments.

It occurs to me that there is a different mental model for attachments that
is worth thinking about. In this model, attachments are not separate
resources, they are part of the state of the resource they are attached to.
When you create an attachment, you are adding to the state of the attachee
- you are not creating a new resource. Obviously, when you delete a
resource all its attachments will disappear since they are part of the
resource's state. When you get a resource with attachments, you may,
depending on your request accept headers, get a multi-part body
(http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) that contains the
attachments as well as a representation of the other state. A crude way of
adding or removing attachments is to POST the whole multi-part thing back -
it would be tempting to invent something additional. It would be possible
to invent URLs that return the portion of the resource state corresponding
to an individual attachment, even though it is not a resource, in the same
way that we invent URLs that can return a single triple of the state of a
resource, even though the triple is not a resource.

One of the reasons I like Dave's non-design is that the more I think about
more complex approaches to attachments, the less obvious it is to me what
the right model is. I think this is one of those problems that is much
harder than originally meets the eye.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690