> From: Dave <[email protected]> > To: [email protected], [email protected] > Date: 06/24/2011 02:06 PM > Subject: [oslc] What should be included in an OSLC SDK Consumer Library? > Sent by: [email protected] > > Here's another topic for discussion from the OSLC SDK proposal. > https://sourceforge.net/apps/mediawiki/oslc-tools/index.php? > title=Proposal_for_OSLC_SDK > > Here are some ideas for what should be in an OSLC SDK Client Library: > > * HTTP Client > - Must support for OAuth and BASIC Auth > - Include and build on an existing open source HTTP client > - Add or augment client's OAuth and BASIC auth support > > * RDF toolkit > - Must support parsing and generating RDF/XML
+ Turtle, N3 > - Include and build on an existing open source RDF toolkit > - Add ability to parse and generate OSLC JSON format + OSLC XML subset format as well + Aligned with W3C RDF/JSON efforts > * OSLC "object model" or some way to: > - Make it easy for folks to create and general OSLC resources > - Make it easy to get resources as objects with properties > > * Other ideas for client library features: > - Ability to validate a resource against a Resource Shape > - Ability to easily iterate through multi-page resources > - Ability to determine Creation URL to use for given resource type > - Ability to determine Query URL to use for given resource type > > * Documentation > - Overview and how-to sections for C.R.U.D. on resources > - API reference for any objects and properties introduced > > Does that sound like the makings of a Client Library? What else should > be present? > > Other issues... > > For other platforms such as PHP, Python, Ruby, etc. what are the best > choices for HTTP clients and RDF toolkits? I didn't see you say Java, perhaps that was just assumed. I like the Apache stack of HTTPClient (with possibly Wink) and Jena for Java consumer library. > > Which of the "other platforms" are most important for OSLC adoption? > Is PHP the #1 priority or Ruby, or Perl? > > Other ideas? I say we should be flexible/agile in how we pursue this plan. We should have a general roadmap and architectural direction. Depending on current active community members (contributors) and their priorities (language binding support, feature, etc) will determine iteration content. Having this plan provides some structure to this work, I just wanted to be clear that it is not intended to be a complete picture but an evolving roadmap and direction. Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645
