[oslc-core] Unrecognized content

[Joe Ross]

For what it's worth, we have a similar problem in our service provider, and
we accept properties with URL values that we don't know about. However, we
don't construct the relationships in our internal model until we have the
target resource. So, someone can create the resources in either order.

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311

> Message: 1
> Date: Fri, 7 Sep 2012 08:55:16 -0400
> From: James Conallen <jconallen at us.ibm.com>
> To: Oslc-Core at open-services.net
> Cc: Adam Neal <Adam_Neal at ca.ibm.com>
> Subject: [oslc-core] Unrecognized content
> Message-ID:
>    <OFE8119FD5.409BF0CC-ON85257A72.0045EEE2-85257A72.0046FA5D at us.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://open-services.net/pipermail/oslc-core_open-
> services.net/attachments/20120907/0d62c7f5/attachment-0001.html>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120907/77ce827a/attachment-0003.html>