Another point to make is that the change I'm proposing is for the OSLC Core spec. OSLC domain specifications are free to tighten this requirement and say MUST provide RDF/XML or MUST provide JSON or whatever is required for the domain's scenarios.
For example, the OSLC-CM v2 spec, which is based on Core, tightens the requirement to a MUST for RDF/XML and JSON: http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;table=up#Resource_Formats Thanks, - Dave On Mon, Jul 26, 2010 at 10:44 AM, Andrew J Berner <[email protected]> wrote: > > Dave wrote: > > > Having a "firm requirement for at least one representation" does help > clients, but we are not there today in our implementations. Today, > OSLC implementations have and will continue to have for some time > limitations in their abilities to provide and accept RDF/XML. Changing > to SHOULD acknowledges fact and still points the way forward. > > The term SHOULD is actually a pretty strong requirement, here's what it > means: > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > > Dave--for the implmentations that don't provide/accecpt RDF/XML, what's the > "valid reason in particular circumstances to ignore" the requirement other > than "they don't". "Should" shouldn't mean "you have to do it, unless you > don't do it, in which case you don't have to." > > I second Samit's concern that unless there is a representation used by all > providers, a client writing code would then have to write separate code for > each provider, which they could do without OSLC by using the native api of > the provider. > > I used to teach a mathematics class for elementary school teachers that was > required for graduation. When a second semester senior failed the course > (for no good reason other than not studying), I was asked to waive the > requirement, because otherwise he couldn't graduate. I didn't, by the way. > > > 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 > >
