I left the per-resource factory off of the wiki page because there was some disagreement about it. I was trying to document only the things we agreed on.
I did say that a service could require an attachment be created by one of the services creation factories. Is that not enough to ensure that the service has control over the lifecycle of the attachment? - Dave On Thu, Feb 3, 2011 at 1:40 PM, Nick Crossley <[email protected]> wrote: > I agree with Jim's comments, and I was surprised to see no mention of the > attachment factory left in the revised discussion. If a service does not > permit free-standing attachment resources, but insists they be related to > the parent resource, then use case #1 needs a slightly different approach: > > 1. The consumer knows the appropriate URI for an attachment factory > (perhaps from the service description), or gets that URI form the parent > resource > 2. The consumer POSTs the attachment to the attachment factory - the > attachment factory URI is specific to the parent resource, or is passed the > parent resource URI as a query string > 3. The attachment factory creates the attachment resource, creates the > link from the parent to the attachment*, and returns the URI of the new > attachment > 4. The consumer adds any additional properties it desires for the > attachment itself, or for the link between the parent and the attachment > 5. > > * In the meeting, someone brought up the question of whether the link > should really go from the parent to the attachment, or from the attachment > to the parent. We did not discuss this in detail, and the wiki page > suggests only the former. > > Nick. > > 1. > > > > > From: James Conallen/Philadelphia/IBM@IBMUS > To: Dave <[email protected]> > Cc: oslc-core <[email protected]>, > [email protected] > Date: 02/03/2011 06:23 AM > Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF > resources > Sent by: [email protected] > ------------------------------ > > > > I think there are a couple of points related to attachment lifecycle that > Nick had mentioned that are critical to the definition of an attachment that > could be added to this document. > > 1. Attachments are deleted when the referencing resource is deleted. > Attachments can be explicitly deleted without deleting the referencing > resource. > 2. Attachments should (must?) be owned an managed by the same provider that > manages the resource that references it. > > <jim/> > > jim conallen > CAM Lead Architect, OSLC AM Lead > [email protected] > Rational Software, IBM Software Group > > > > [image: Inactive hide details for Dave ---02/03/2011 08:19:05 AM---We had a > good discussion of the topics of Attachments and Non-RDF Re]Dave > ---02/03/2011 08:19:05 AM---We had a good discussion of the topics of > Attachments and Non-RDF Resources. I think that some were > > From: Dave <[email protected]> > To: oslc-core <[email protected]> > Date: 02/03/2011 08:19 AM > Subject: Re: [oslc-core] Core WG topic: Attachments and non-RDF resources > Sent by: [email protected] > ------------------------------ > > > > We had a good discussion of the topics of Attachments and Non-RDF > Resources. I think that some were confused because I was conflating > the two topics and covered many approaches, including an overly > complex one, but I think it was useful to discuss both topics > together. > > To follow up, I have written a page that focuses on Attachments only. > Here's what I believe are the three important use cases for > attachments and a simple pattern for each: > > > *http://open-services.net/bin/view/Main/OslcCoreAttachments*<http://open-services.net/bin/view/Main/OslcCoreAttachments> > > I think we want all domains to handle attachments in a consistent way, > so perhaps we should work to create a guidance document? Other ideas? > > As always, feedback is most welcome. > > Thanks, > - Dave > > > > > On Tue, Feb 1, 2011 at 4:17 PM, Dave <[email protected]> wrote: > > At the Core WG meeting tomorrow, we'll be discussing how to handle > > Attachments and non-RDF Resources. > > > > *http://open-services.net/bin/view/Main/OslcCoreMeeting20110202*<http://open-services.net/bin/view/Main/OslcCoreMeeting20110202> > > > > I'll be using this presentation to explore various approaches: > > * > http://open-services.net/pub/Main/OslcCoreMeeting20110202/attachments.pdf*<http://open-services.net/pub/Main/OslcCoreMeeting20110202/attachments.pdf> > > > > Whether you can attend the meeting or not your feedback is most welcome. > > > > Thanks, > > Dave > > > > _______________________________________________ > Oslc-Core mailing list > [email protected]* > **http://open-services.net/mailman/listinfo/oslc-core_open-services.net*<http://open-services.net/mailman/listinfo/oslc-core_open-services.net> > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > >
