[oslc-core] Unrecognized content

Fri Sep 7 12:07:39 EDT 2012

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.

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

Inactive hide details for Arthur Ryman ---09/07/2012 10:15:00 AM----1 for
the 400 response code Jim, I don't understand what yoArthur 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120907/d5650f83/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/20120907/d5650f83/attachment.gif>