+1 When I was looking at RFC2119 before as well, none seemed to be a direct hit of the intent of this.
Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > From: Jim des Rivieres <[email protected]> > To: Ian Green1 <[email protected]> > Cc: [email protected] > Date: 09/28/2010 12:13 PM > Subject: Re: [oslc-core] Proposed language / modifications to "Range" definition > Sent by: [email protected] > > +1 I think this gets the right amount of clarity and nuance: > > Description: The target resource is a related change request. It is likely > that the target resource will be a ChangeRequest, but that is not > necessarily the case. > > > > From: > Ian Green1 <[email protected]> > To: > [email protected] > Date: > 09/28/2010 10:58 AM > Subject: > Re: [oslc-core] Proposed language / modifications to "Range" > definition > Sent by: > [email protected] > > > > RFC2119 MAY is being used here as a hint - setting an expectation. > > My suggestion is to put some non-normative text along the lines of "it is > likely that the target resource will be a ChangeRequest, but that is not > necessarily the case". > > Description: The target resource is a related change request. The > target resource MAY be another oslc_cm:ChangeRequest resource. > > > best wishes, > -ian > > [email protected] (Ian Green1/UK/IBM@IBMGB) > Chief Software Architect, Requirements Definition and Management > IBM Rational > > [email protected] wrote on 28/09/2010 14:47:12: > > > [image removed] > > > > Re: [oslc-core] Proposed language / modifications to "Range" definition > > > > Steve K Speicher > > > > to: > > > > Andrew J Berner > > > > 28/09/2010 14:47 > > > > Sent by: > > > > [email protected] > > > > Cc: > > > > oslc-core, oslc-cm > > > > Andrew J Berner/Dallas/IBM wrote on 09/28/2010 09:21:19 AM: > > > > > From: Andrew J Berner/Dallas/IBM > > > To: Steve K Speicher/Raleigh/IBM@IBMUS > > > Cc: Jim des Rivieres <[email protected]>, > > [email protected], > > > [email protected], [email protected] > > > Date: 09/28/2010 09:22 AM > > > Subject: Re: [oslc-core] Proposed language / modifications to "Range" > > definition > > > > > > So I understand the purpose of not requiring the type. At some point > we > > may > > > consider whether the type has to support a particular "interface" so > > that I > > > can count on it "knowing" relevant information, but let's not go there > > > > right now. > > > > > > But we don't want to throw out the value of typing while allowing late > > > > > binding....If I do know the type (like "often the target resource is > > another > > > oslc_cm:ChangeRequest resource) then there is more that I can do with > > it, > > > since I have (in my imagination) written my client to use information > > from > > > such targets. Can I find out in advance if it is, without having to > > fetch it? > > > I may be "out of date"---it the type returned in a header, so I can at > > > > worst > > > have to make a cheap "HEAD" call instead of a GET? Is the type of the > > > > target > > > inlined in the link? Unlike attributes of the target that we should > NOT > > be > > > denormalizing, that wouldn't change, right? > > > > You can perform a HEAD operation setting an Accept header of what you > > want, say RDF/XML or JSON or plain XML. You can determine if the > service > > provider supports this. If it does then, take for example, a request > for > > RDF/XML could determine what kind of resource it is based on parsing if > > you locate the expected rdf:type or locate your properties of interest. > > Additionally, you could attempt a partial fetch and inspect the result > to > > see if it is something you can work with. > > > > The key point is, if we build this tight bindings across systems based > on > > the "type" of resource, we lose some of the flexibility we get from our > > loose-coupled architecture. So it may be the case that certain use > cases > > may not work if the client can't locate certain properties on that > > resource but this is not a problem. We just want to be clear in the > spec > > that clients should support this behavior. > > > > Thanks, > > Steve Speicher | IBM Rational Software | (919) 254-0645 > > > > > > _______________________________________________ > > Oslc-Core mailing list > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > _______________________________________________ > 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
