[oslc-core] Attachments

Mon Feb 7 18:04:10 EST 2011

To me this sounds like there is not a sufficiently compelling reason to
specify anything new, beyond perhaps explaining how Dave's non-design can
be applied to attachments. How would we poll the stakeholders to test that
assertion?

Best regards, Martin

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

|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Nick Crossley/Irvine/IBM                                                                                                                          |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |James Conallen/Philadelphia/IBM at IBMUS                                                                                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Martin Nally/Raleigh/IBM at IBMUS, oslc-core at open-services.net@                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |02/07/2011 04:54 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] Attachments                                                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

I do not have a strong opinion on this either.  I agree that the simple
'create a separate resource and then link it' approach that Dave has
written up is so simple that it need not be described - and describing it
as an attachment pattern might be misleading.  If we do feel the need to
define a recommended pattern for the more complex cases, I have no strong
preference between a multipart approach vs. a creation factory approach, or
any other.  Since different use cases might lead service providers to make
different choices here, I'm not convinced that recommending a single
pattern is even appropriate.

As far as common properties are concerned, I'm not convinced that we should
define an oslc:attachment property at this stage, since I do not think we
have an agreed common type or representation of such a property.

BTW, the SCM domain does not currently define or use attachments.  My
examples of attachments that had dependent life cycles came primarily from
the CM domain, with attachments to change requests.

Nick.

-----oslc-core-bounces at open-services.net wrote: -----
 To: Martin Nally/Raleigh/IBM at IBMUS
 From: James Conallen/Philadelphia/IBM at IBMUS
 Sent by: oslc-core-bounces at open-services.net
 Date: 02/07/2011 01:31PM
 Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
 Subject: Re: [oslc-core] Attachments

 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

 (Embedded image moved to file: pic07231.gif)Martin Nally---02/07/2011
 03:27:54 PM---I thought some more about attachments in the shower. The
 design I still like the best is Dave's non-

 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

 _______________________________________________
 Oslc-Core mailing list
 Oslc-Core at open-services.net
 http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic07231.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110207/03de371c/attachment.gif>