[OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET
Andrew J Berner
ajberner at us.ibm.com
Sun Jan 17 18:03:20 EST 2010
An issue that has come up in several of the workgroups I'm attending: The
storage of a resource may be very different from the XML representation of
the resource you GET from the URL. The spec defines the representation you
GET and PUT, not the underlying storage mechanism. The XML representation
specified in the OSLC spec may be derived by the server from the data
This raises a question about the spec: Have we been specifying ways of
GETting alternate representations of the same resource? I'm wondering if
there shouldn't be a somewhat standardized way to do this, although the
specifics will be resource dependent.
As I look over some of the specs, it seems we are defining a single XML
format for each resource. In some cases, that may make sense--the resource
IS the XML document. But in other cases, the resource is more abstract.
Even if we expect the stream returned by an OSLC GET call to always be an
XML document, there may be variations in the XML representation of a
particular resource that could be important to be specified by the request.
One example of this is will show up in the Estimation OSLC spec: the
representation of estimated duration (or other key metrics) of a project.
It's not a single number, but rather a probability distribution, so you can
say the probability of completing the project in that amount of time. It's
a formalized representation of something like this: "it's 50% likely we
can complete it in 24 months, but if you want to be 75% confident, plan for
35 months and it's barely possible it could take over 4 years. There's a
25% chance you can get lucky and finish in 16 months, but the 12 month
schedule you asked for is impossible! The least it will be is 14 months."
Although "probability distribution" is an abstract mathematical construct,
the XML representation that will be in the estimation OSLC spec is a
quantile representation, which will be "good enough" for consumers. It
will be an XML representation of some of the values of the probability
distribution, but it can be at various granularities. It will list the
values of the distribution for evenly spaced percentages as a sequence of
values in the XML document--the client can figure out which percentage each
represents based on the number of elements and the order of the elements.
Here's an example of the informal description above, based on a similar
example from the WIKI:
Now, for some purposes, a client may want a representation of the
distribution at a fairly high granularity, like the one above, at the 25%,
50% and 75% probabilities, maybe to get a ballpark of how risky the
schedule will be. For other purposes, a client may want a representation
at a detailed granularity, getting each percentage probability, perhaps to
answer the question, "what's the probability I can finish by Dec 1?" and
get an answer like "68%". I'll spare you the similar but much longer XML
representation of the same resource (the probability distribution) but with
100 quantiles :-).
This is just an example; I suspect each workgroup has examples like this,
where there can be different levels of detail or other variations returned
by a GET, all formatted by the interface provider from the same abstract
resource. It's related, but not quite the same I think, as the standard
issue of "partial retrieves" in queries (which I've started to hear
described as the "shape of the returned set"). So there needs to be a way
for the consumer to negotiate with the provider, or, more simply, just tell
the provider how the consumer wants the resource represented, even if all
the representations are in XML.
Even though the "choices" of representation are resource dependent (e.g.
"number of quantiles" for a probability distribution), is there a general
technique we'll use in the various OSLC specs to specify requested
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
ajberner at us.ibm.com
Ready for IBM Rational software partner program -
More information about the Community