Ian/Andy, In Andy's example, the media type is the same in both cases, i.e. application/rdf+xml. It is the content that is different, i.e. requesting quartiles (4 quantiles) versus percentiles (100 quantiles). The way to get different content is application-dependent.
In the example, the workflow that initiated the creation of estimate should specify the number of quantiles desired. Another way to request different content is via query parameters on the URL. For example, the application could define a query parameter like so to request percentiles: http://braintwistors.example.com/ems10/Estimate/7263?ems:numberOfQuantiles=100 In this case the service might re-express the estimate as percentiles instead of quartiles (presumably by interpolation). Arthur Ryman, IBM DE Chief Architect, Rational Project and Portfolio Management Office: 905-413-3077, Cell: 416-939-5063 Assistant: Nancy Barnes, 905-413-4182 Ian Green1 <[email protected]> Sent by: [email protected] 01/18/2010 12:34 PM To Andrew J Berner <[email protected]> cc [email protected], [email protected] Subject Re: [OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET I don't see these as different representations; the mediatype defines the format, not the content. it would lead to a proliferation of media types were we to use a different one for each of these variants. best wishes, -ian [email protected] (Ian Green1/UK/IBM@IBMGB) Chief Software Architect, Requirements Definition and Management IBM Rational From: Andrew J Berner <[email protected]> To: Geoffrey M Clemm <[email protected]> Cc: [email protected], [email protected] Date: 18/01/2010 01:41 Subject: Re: [OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET Sent by: [email protected] Good answer, Geoff, that's the usual way for different representations to be negotiated, so that's a good standard to follow. And it's just a string, so we could choose anything we want I suppose for what is "legal" to request in the ACCEPT header to deal with the variants allowed for each resource. That's more or less analogous to the type of a parameter in a method signature. So should the OSLC specs then be defining the allowed values (or formats, if it's not just a simple list of values) for the ACCEPT header, and how does that get discovered? Are there tools that help the programmer provide a "legal" value? Andy Berner Lead Architect, ISV Technical Enablement and Strategy IBM Rational Business Development 972 561-6599 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Geoffrey M Clemm/Lexington/IBM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Andrew J Berner/Dallas/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected], [email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/17/2010 06:53 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET | >--------------------------------------------------------------------------------------------------------------------------------------------------| With HTTP, one requests a variant of the representation with the ACCEPT header. If one cannot encode the variant information in the ACCEPT header, I suppose one could define a URL parameter for it. Cheers, Geoff |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Andrew J Berner/Dallas/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |01/17/2010 06:04 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[OSLC] resource: storage vs representation--specifying variations in the form of the return from a GET | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| 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 stored. 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: <ems:QuantileFunction ems:metric="http://open-services.net/software-metrics/duration"; ems:unitOfMeasure="month" ems:numberOfQuantiles="4"> <ems:low>14</ems:low> <ems:quantile>16</ems:quantile> <ems:quantile>24</ems:quantile> <ems:quantile>35</ems:quantile> <ems:high>50</ems:high> </ems:QuantileFunction> 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 variations? Andy Berner Lead Architect, ISV Technical Enablement and Strategy IBM Rational Business Development 972 561-6599 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_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 _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
