[oslc-core] OSLC, openness and media types
Martin Nally
nally at us.ibm.com
Mon Jan 10 12:37:35 EST 2011
The basic guidance for a client when following a link that crosses between
OSLC specifications is to act like a browser, in the sense that you do not
make any assumptions about what will be at the other end. A client should
look first at the media-type, and for generic media types like XML or RDF,
the namespaces in the content, in order to figure out how to process the
resource at the end of the link. If the resource at the end of a
cross-specification link turns out to be a JPEG instead of an
OSLC-specified resource, that is not an error, and the client needs to be
prepared.
There are different schools of thought in the industry around the use of
media types. One school believes that it's a good idea to invent new media
types for "application domains" and even for particular versions of
application domains. Another school says that inventing media types is a
bad idea and you shouldn't do it. OSLC chose to take the second view. The
arguments for this view are:
If you create custom media types, you make it impossible for generic
software to work against your resources. A simple example is a crawler.
Crawlers understand generic media types like HTML, RDF or XML. If you
use custom types, crawlers won't work against your resources. This is a
major disadvantage. Crawlers are just one example of generic software.
Namespaces in XML or RDF already provide powerful mechanisms for
expressing versions, so you don't need to use media types for this
purpose
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-core-request at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-core at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|01/10/2011 12:03 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Oslc-Core Digest, Vol 12, Issue 7 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-core-bounces at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Send Oslc-Core mailing list submissions to
oslc-core at open-services.net
To subscribe or unsubscribe via the World Wide Web, visit
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
or, via email, send a message with subject or body 'help' to
oslc-core-request at open-services.net
You can reach the person managing the list at
oslc-core-owner at open-services.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oslc-Core digest..."
Today's Topics:
1. Re: What can an OSLC spec claim? What can a client assume?
(Steve K Speicher)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Jan 2011 10:34:33 -0500
From: Steve K Speicher <sspeiche at us.ibm.com>
To: Paul Komar <pkomar at us.ibm.com>
Cc: oslc-core at open-services.net
Subject: Re: [oslc-core] What can an OSLC spec claim? What can a
client assume?
Message-ID:
<OFCF601E98.295EC996-ON85257814.004EE445-85257814.00558FBE at us.ibm.com>
Content-Type: text/plain; charset="US-ASCII"
Hi Paul,
I've included some responses inlined below.
> From: Paul Komar/Lexington/IBM at IBMUS
> To: oslc-core at open-services.net
> Date: 01/06/2011 04:16 PM
> Subject: [oslc-core] What can an OSLC spec claim? What can a client
assume?
> Sent by: oslc-core-bounces at open-services.net
>
> Last month Martin Nally wrote "
> I think this confirms that the only safe option for a client is to
assume
> nothing. I think the spec should say this."
>
> Can you please help me understand how a person can implement a client of
a
> service whose specification is based upon that much ambiguity?
> (I got the impression from reading some historical notes from WebDAV
client
> implementers that while the spec might be written to allow varying
degrees of
> sophistication of service implementations, they would have preferred a
> tighter, more constrained spec.)
The intent of this guidance is to make it very clear that the motivation
is to build flexible integrations that span time, upgrades, technology
choices, etc.
So for some scenarios, clients may depend on certain resource formats and
expect certain properties. That won't change. OSLC style of integration
again focuses on loosely-coupled integrations, whereas efforts like WebDAV
focused on very specific client-server interaction of SCM tools.
> Arthur Ryman replied to "I agree that clients should be able to
gracefully
> handle unexpected
> responses."
> It seems to me that clients can gracefully decline to provide the
desired
> behavior when the server doesn't give the client what it needs.
>
> Consider a use case where a client must get information from a service
and
> then use the information in the response to get more information
(possibly
> from another service). If the first service does not provide the
requested
> information, then the client cannot complete the use case.
>
> Also, I'm curious to learn how to write good compliance tests if the
client
> can assume nothing.
In having just contributed a test suite, the test suite can assume it is
speaking to services that claim a level of support. A test suite is not
necessarily a well-behaved client in this way.
> While the Rest/OSLC world may want to be more flexible than the UML
world
> (with its effective requirement of transitive closure across domains, as
> Martin also wrote about), OSLC services must provide the information in
a
> consumable way, right? I thought that the Restful way to handle version
> upgrades was to use media types that provided compatible ways to add
> information in subsequent versions, but allow older/smaller clients to
use the
> older/smaller content.
>
> It seems to me that a Rest/OSLC client might have to have a "broader"
> expectation of valid responses than an client from the UML world.
(Perhaps
> there's an equivalence class of useful responses?)
>
> In summary, I wonder if Martin or Arthur could write up a pattern for
good
> OSLC client implementations.
> Maybe there would be a rule like " don't validate that the response is
what
> you expect, instead look in the response for the information that you
require"?
As you stated it is not a bad way to think about it. The Core WG is
starting to build up primers and other material to help guide
implementers. This is good input to that effort for consideration on
writing well-behaved OSLC clients.
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
------------------------------
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
End of Oslc-Core Digest, Vol 12, Issue 7
****************************************
More information about the Oslc-Core
mailing list