[oslc-core] Unrecognized content

Tue Sep 11 08:46:36 EDT 2012

The crux of the problem is; we want clients to easily know if the request
to change a resource (e.g. add or remove a link) was successful or not.

According to the OSLC spec a server can "discard unknown property values".
This puts the onus on the client to know what the server knows or doesn't
know. (starting to sound like Rumsfeld :-)

I can think of four things to address this:

1) If a client PUTs a resource, the server SHOULD respond with an OK, and
the resource's current ETag.  The client must GET it back, and compare the
ETag with the one that was sent.  If the ETags (and resource contents) are
the same, then it knows that the PUT did not take, and I guess it knows
that whatever link type property it tried to add is 'unknown' to the
server.

2) The server must return the current value of the modified resource in the
response to a PUT.  The client can examine the contents to see if the link
'stuck'.

3) Service providers MUST provide shapes that include the link type
properties that it is willing to accept.  The client will know ahead of
time whether the link should stick or not.

4) Servers can return a 400 Bad Request, when a PUT does not result in a
changed resource (as per the PUT spec).

Regardless of what we suggest as appropriate guidance, I think we need to
update the section of the spec to make clearer what the issues are in
saying a server can "discard unknown property values" and how it affects
resource management.

Thanks,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group

From:	Ian Green1 <ian.green at uk.ibm.com>
To:	Frank Budinsky <frankb at ca.ibm.com>,
Cc:	Adam Neal <Adam_Neal at ca.ibm.com>, James
            Conallen/Philadelphia/IBM at IBMUS, Oslc-Core at open-services.net,
            oslc-core-bounces at open-services.net
Date:	09/11/2012 08:25 AM
Subject:	Re: [oslc-core] Unrecognized content

Frank - My recollection is that asking providers to accept all properties
would hinder adoption.  There may have been other pressures too (I don't
recall).

The issue that Jim describes seems to me to highlight a gap between the
spec and the use cases that we're trying to satisfy.   Creating a link is
one of the bread-and-butter operations and it seems that the spec makes it
awkward for clients to establish whether a simple link creation was
successful or not.

best wishes,
   -ian

ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
IBM Rational

oslc-core-bounces at open-services.net wrote on 07/09/2012 17:07:39:

> From: Frank Budinsky <frankb at ca.ibm.com>
> To: James Conallen <jconallen at us.ibm.com>,
> Cc: oslc-core-bounces at open-services.net, Oslc-Core at open-
> services.net, Adam Neal <Adam_Neal at ca.ibm.com>
> Date: 07/09/2012 17:07
> Subject: Re: [oslc-core] Unrecognized content
> Sent by: oslc-core-bounces at open-services.net
>
> This seems like an odd description anyway. If the server MAY discard
> property values, shouldn't the spec say that the client MUST assume
> that the service will discard ... (as opposed to SHOULD)? There
> doesn't seem to be a choice for the client unless it knows the
> server implementation (which is bad design practice and would also
> require no assuming).
>
> I also wonder why this design was chosen over the more flexible
> approach of requiring servers to round-trip properties that they
> don't recognize? They can ignore them (i.e., treat them like open
> content) but they can't silently throw them away.
>
> Frank.
>
> [image removed] James Conallen ---09/07/2012 11:19:27 AM---Hey
> Arthur, The spec for the PUT method says:
>
> From: James Conallen <jconallen at us.ibm.com>
> To: Arthur Ryman/Toronto/IBM at IBMCA,
> Cc: Oslc-Core at open-services.net, Adam Neal/Ottawa/IBM at IBMCA, oslc-
> core-bounces at open-services.net
> Date: 09/07/2012 11:19 AM
> Subject: Re: [oslc-core] Unrecognized content
> Sent by: oslc-core-bounces at open-services.net
>
>
>
> 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
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
>
> [image removed] Arthur Ryman ---09/07/2012 10:15:00 AM----1 for the
> 400 response code Jim, I don't understand what you are asking for.
> The spec already makes
>
> From: Arthur Ryman <ryman at ca.ibm.com>
> To: James Conallen/Philadelphia/IBM at IBMUS,
> Cc: Adam Neal <Adam_Neal at ca.ibm.com>, Oslc-Core at open-services.net,
> oslc-core-bounces at open-services.net
> 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 <jconallen at us.ibm.com>
> To:
> Oslc-Core at open-services.net
> Cc:
> Adam Neal/Ottawa/IBM at IBMCA
> Date:
> 09/07/2012 09:03 AM
> Subject:
> [oslc-core] Unrecognized content
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> 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
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
> _______________________________________________
> 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
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120911/3fb175f3/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/20120911/3fb175f3/attachment.gif>