[oslc-core] Attachments

[James Conallen]

Actually I don't have any strong opinions on any of the approaches.  In my
opinion attachments are just resources that we don't expect to parse, and
can be expected be provided back when asked.  Whether or not they are
managed by the attachee's managing provider is really just one way to
facilitate its lifecycle being tied to that of the attachee resource. In
the SCM domain it is important that the lifecycle of an attachment resource
is closely associated with the 'atachee' resource.

In the AM domain this is not so important, and we can probably get away
with it just being another reference property.

What I think is more important is; should the OSLC Core define a common
property called 'attachment' or not?  Is this a re-usable property like
title, and description?  When spec writers need to have an attachment like
mechanism to support scenarios in their domain, should they reuse this oslc
'attachment' property, or create a property in their domain (possibly
defining a cm:attachment, rm:attachment, qm:attachment, and am:attachment
property in each domain)?

If we don't define such a property then all the domains are free to use
what ever mechanism is most appropriate for their domain (i.e. SCM adopting
a formal Attachment resource to help manage the meta information it needs,
and CM using a simple cm:attachment property pointing to any resource
managed by any server).

I think the model that an attachment is actually part of the state of the
resource itself is an interesting one.  At first thought, it didn't strike
me as what most people consider an attachment (something stapled to some
form that supplies supplementary information).  But when I think of an
attachment to an email, it may not affect the text in the email, but the
overall message may be changed by it, and hence it has a different state.

By the way, this model of attachments obviously fulfills Nick's needs to
manage the life cycle of the attachment resource.  When the resource is
deleted, all its state contributing resources could be considered deleted
(or at the very least not reachable through the original resource's URI).

If we adopt this approach (or any approach), I think spec writers and
clients would appreciate the OSLC Core to define a recommended pattern for
dealing with 'attachment' like things.


<jim/>

jim conallen
CAM Lead Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group





From:	Martin Nally/Raleigh/IBM at IBMUS
To:	oslc-core at open-services.net,
            oslc-core-bounces at open-services.net
Date:	02/07/2011 03:27 PM
Subject:	[oslc-core] Attachments
Sent by:	oslc-core-bounces at open-services.net



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


_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110207/da572601/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110207/da572601/attachment.gif>