At first edit, missed Arthur's approved suggestion to "MUST". Fixed that.
Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net "Oslc-Core" <[email protected]> wrote on 10/17/2012 10:03:40 AM: > From: Steve K Speicher/Raleigh/IBM@IBMUS > To: [email protected], > Date: 10/17/2012 10:12 AM > Subject: Re: [oslc-core] Unrecognized content > Sent by: "Oslc-Core" <[email protected]> > > I have incorporated this change with slight editorial changes [1]. > This closes Issue-16 [2] > > [1] - http://open-services.net/bin/view/Main/OslcCoreSpecification?rev=72 > [2] - http://open-services.net/wiki/core/OSLC-Core-V2-Issues/ > > Thanks, > Steve Speicher > IBM Rational Software > OSLC - Lifecycle integration inspired by the web -> > http://open-services.net > > Arthur Ryman <[email protected]> wrote on 09/23/2012 09:40:41 PM: > > > From: Arthur Ryman <[email protected]> > > To: James Conallen/Philadelphia/IBM@IBMUS, > > Cc: [email protected], [email protected], > Steve > > K Speicher/Raleigh/IBM@IBMUS > > Date: 09/23/2012 09:40 PM > > Subject: Re: [oslc-core] Unrecognized content > > > > Jim, > > > > +1 except for stronger wording about errors: > > > > A Service provider MUST return an error code if recognized content is > > invalid. > > > > Regards, > > > ___________________________________________________________________________ > > > > > Arthur Ryman > > > > DE, Chief Architect, Reporting & > > Portfolio Strategy and Management > > IBM Software, Rational > > > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > > > > > > > From: > > James Conallen <[email protected]> > > To: > > Steve K Speicher <[email protected]> > > Cc: > > [email protected], [email protected] > > Date: > > 09/18/2012 09:16 AM > > Subject: > > Re: [oslc-core] Unrecognized content > > Sent by: > > [email protected] > > > > > > > > Ok, how about this update for the Unknown properties and content > section: > > > > For OSLC Defined Resources, clients SHOULD assume that an OSLC Service > > will discard unknown property values. An OSLC Service MAY discard > property > > values that are not part of the resource definition or Resource Shape > > known by the server. If a client needs verification that the requested > > update was accepted it SHOULD note the ETag returned with the PUT, then > > immediately GET the resource back and compare the ETag and contents with > > > its expectations. The Service SHOULD not return an error code for > > unrecognized content. A Service provider MAY return an error code if > > recognized content is invalid. > > > > The rule is different for clients. When doing an update, OSLC clients > MUST > > preserve any unknown property-values and other content in OSLC Defined > > Resources. > > > > > > Thanks, > > > > jim conallen > > Rational Design Management (DM) Integration Architect, OSLC AM Lead > > [email protected] > > Rational Software, IBM Software Group > > > > > > > > Steve K Speicher---09/18/2012 08:51:25 AM---+1 We are saying it can > > happen, we just need a proposal for how clients can learn this. We > > require > > > > From: Steve K Speicher/Raleigh/IBM@IBMUS > > To: [email protected], > > Date: 09/18/2012 08:51 AM > > Subject: Re: [oslc-core] Unrecognized content > > Sent by: [email protected] > > > > > > > > +1 We are saying it can happen, we just need a proposal for how clients > > can learn this. We require a round trip now: PUT, GET, then check. > > > > Steve Speicher > > IBM Rational Software > > OSLC - Lifecycle integration inspired by the web -> > > http://open-services.net > > > > > From: Arthur Ryman <[email protected]> > > > To: James Conallen/Philadelphia/IBM@IBMUS, > > > Cc: [email protected], Adam Neal <[email protected]>, > oslc- > > > [email protected] > > > Date: 09/14/2012 01:59 PM > > > Subject: Re: [oslc-core] Unrecognized content > > > Sent by: [email protected] > > > > > > Jim, > > > > > > I think we may be stretching the analogy here. > > > > > > I am OK with you proposal: "I am ok if we just state that this > scenario > > > can happen, and that the client is responsible for determining if the > > > update was successful (from its view) by GETing the representation > > > immediately after and checking the content and comparing the ETags." > > > > > > Pls draft some text and say where it should be included so we have a > > > concrete proposal on the table. > > > > > > Regards, > > > > > > ___________________________________________________________________________ > > > > > > > > > > > Arthur Ryman > > > > > > DE, Chief Architect, Reporting & > > > Portfolio Strategy and Management > > > IBM Software, Rational > > > > > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > > > > > > > > > > > > > From: > > > James Conallen/Philadelphia/IBM@IBMUS > > > To: > > > Arthur Ryman/Toronto/IBM@IBMCA > > > Cc: > > > Adam Neal <[email protected]>, [email protected], > > > [email protected] > > > Date: > > > 09/13/2012 04:44 PM > > > Subject: > > > Re: [oslc-core] Unrecognized content > > > > > > > > > Arthur, > > > > > > While I am not advocating that we respond with a 4xx when the server > > does > > > not update a resource at a client's request. I point it out as an > > example > > > of how even RFC2616 requires some interpretation in context. > > > > > > What I do want to do is address this very real problem (that DM and > RRC > > > are experiencing) that clients have when attempting to update > resources > > > (in general). > > > > > > Using your own Java analogy, a program that essentially is > > > > > > x = -42; > > > out.println( x ); > > > > > > where the output is +42, because this particular type of variable only > > > > understands positive integers, and the programmer doesn't know this. > Now > > > > > > > he is forced to check every time he makes an assignment before > > proceeding > > > with the program > > > > > > x = -42; > > > if( x != -42 ) throw exception > > > > > > I think because the OSLC explicitly says that the server can ignore > > > unrecognized content, and there is no guaranteed way for a client to > > know > > > what content the server recognizes, the onus is on the client to be > > > responsible for checking the results. I think we should provide some > > > guidance and raise awareness of this scenario in our specs > > > (non-normatively), so client developers can be prepared for this > > > situation. > > > > > > I am ok if we just state that this scenario can happen, and that the > > > client is responsible for determining if the update was successful > (from > > > > > > > its view) by GETing the representation immediately after and checking > > the > > > content and comparing the ETags. > > > > > > > > > Thanks, > > > > > > jim conallen > > > Rational Design Management (DM) Integration Architect, OSLC AM Lead > > > [email protected] > > > Rational Software, IBM Software Group > > > > > > > > > > > > > > > > > > > > > From: Arthur Ryman/Toronto/IBM@IBMCA > > > To: James Conallen/Philadelphia/IBM@IBMUS, > > > Cc: Adam Neal <[email protected]>, [email protected], > > > > [email protected] > > > Date: 09/13/2012 04:03 PM > > > Subject: Re: [oslc-core] Unrecognized content > > > > > > > > > Jim, > > > > > > I disagree. The server ignored the content it didn't understand and > did > > > the update, but the before and after state was the same. According to > > your > > > proposal, if I did a GET and then immediately PUT the resource, that > > > should also result in an error because nothing changed. That would not > > > be > > > reasonable. > > > > > > Consider the following Java program: > > > > > > int x = 42; > > > x = 42; > > > > > > That shouldn't result in a compiler error. > > > > > > In fact, the behavior of the server is somewhat undefined if a PUT > would > > > > > > > result in no change to the resource. The server could try to be clever > > > and > > > only update the resource if some property changed. Or it could take > the > > > request literally and replace the resource with an identical copy, but > > > as > > > a side affect, the modification date of the resource might change. > > > > > > > > > Regards, > > > > > > ___________________________________________________________________________ > > > > > > > > > > > Arthur Ryman > > > > > > DE, Chief Architect, Reporting & > > > Portfolio Strategy and Management > > > IBM Software, Rational > > > > > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > > > > > > > > > > > > > > > > From: > > > James Conallen/Philadelphia/IBM@IBMUS > > > To: > > > Arthur Ryman <[email protected]> > > > Cc: > > > Adam Neal <[email protected]>, [email protected], > > > [email protected] > > > Date: > > > 09/07/2012 11:16 AM > > > Subject: > > > Re: [oslc-core] Unrecognized content > > > > > > > > > Hey Arthur, > > > > > > The spec for the PUT method says: > > > > > > If an existing resource is modified, either the 200 (OK) or 204 (No > > > Content) response codes SHOULD be sent to indicate successful > completion > > > > > > > of the request. If the resource could not be created or modified with > > the > > > Request-URI, an appropriate error response SHOULD be given that > reflects > > > > > > > the nature of the problem. > > > > > > In this scenario the server did not modify the resource, because it > > didn't > > > recognize the content. So according to RFC 2616 we should be > returning > > an > > > error response. > > > > > > > > > Thanks, > > > > > > jim conallen > > > Rational Design Management (DM) Integration Architect, OSLC AM Lead > > > [email protected] > > > Rational Software, IBM Software Group > > > > > > > > > > > > > > > > > > > > > From: Arthur Ryman <[email protected]> > > > To: James Conallen/Philadelphia/IBM@IBMUS, > > > Cc: Adam Neal <[email protected]>, [email protected], > > > > [email protected] > > > Date: 09/07/2012 10:15 AM > > > Subject: Re: [oslc-core] Unrecognized content > > > > > > > > > > > > -1 for the 400 response code > > > > > > Jim, I don't understand what you are asking for. The spec already > makes > > it > > > > > > clear that the server will discard unrecognized content. The client > > should > > > > > > expect that. What aspect of behavior is unclear? > > > > > > Regards, > > > > > > ___________________________________________________________________________ > > > > > > > > > > > > > > Arthur Ryman > > > > > > DE, Chief Architect, Reporting & > > > Portfolio Strategy and Management > > > IBM Software, Rational > > > > > > Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) > > > > > > > > > > > > > > > > > > From: > > > James Conallen <[email protected]> > > > To: > > > [email protected] > > > Cc: > > > Adam Neal/Ottawa/IBM@IBMCA > > > Date: > > > 09/07/2012 09:03 AM > > > Subject: > > > [oslc-core] Unrecognized content > > > Sent by: > > > [email protected] > > > > > > > > > > > > In the current specification we have the statement: > > > For OSLC Defined Resources, clients SHOULD assume that an OSLC Service > > > > will discard unknown property values. An OSLC Service MAY discard > > property > > > > > > values that are not part of the resource definition or Resource Shape > > > known by the server. > > > > > > We are running into a problem. When a client (in this case another > > > application server) PUTs an update to a resource that includes a > 'link' > > to > > > > > > another OSLC resource, and the server, at the time does not recognize > > the > > > link type, the link is not accepted, but a 200 OK is returned. The > > server > > > > > > returns a 200 OK, because it feels like it can ignore the unrecognized > > > > link. The client gets that 200 OK, and thinks that the link was > > > successfully added. > > > > > > This doesn't feel right. The only way a client can be sure that the > PUT > > > > > > > worked as expected is to re-GET the resource and compare it to what it > > > > expected to see (with the new link included), and maybe do a little > > > looking at ETags to make sure things haven't changed in between. > > > > > > I guess the server could instead return a 400 Bad Request, and include > > > in > > > the response the reason for not accepting the PUT. But if the content > > > > that was submitted really should just be ignored (i.e. is part of a > > future > > > > > > version of the resource), then we don't want to abort the update. > > > > > > The OSLC verbage does not provide any guidance as to what to do. It > > would > > > > > > be helpful if we had more detailed explanation of this statement in > the > > > spec. > > > > > > > > > Thanks, > > > > > > jim conallen > > > Rational Design Management (DM) Integration Architect, OSLC AM Lead > > > [email protected] > > > Rational Software, IBM Software Group > > > _______________________________________________ > > > 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 > > > > > > > > > _______________________________________________ > > 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 > > > > > > > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
