Olivier wrote: > And I'm a bit fearful that OSLC turns to a too complex thing to ever > achieve some potential of being a standard in the ALM field, if it > becomes too hard to grasp (at least for the core mandatory concepts).
This is a critical point! We need to pay attention to the consumability of the specs, both for implementers and consumers. Especially to many consumers, "using OSLC" will not necessarily be a key part of their job, but they will need to create integrations to OSLC providers in as productive and inexpensive away as they can. So there must be an easy way to incorporate the OSLC interfaces into their standard programming practices. That's one of the purposes of OSLC, and we must make sure we both keep the spec "as simple as possible but no simpler" (thus some of the discussion about required formats), and when there is essential complexity (perhaps to deal with the variations captured by Shape), then there are supplementary tools and materials to help with consumption. For example, while the "language neutral" nature of HTTP, XML, RDF etc. probably allows even LISP programmers to consume OSLC, in practice, using the interface requires a 3GL language binding, and having some "canned" ones for the most common languages (we can debate the list) will go a long way to help use this with all the helpers that modern IDE's provide. As well as making sure (as many notes over the last months have tried to help do) that we build the spec so it can use common tools for the core technologies (for example, making sure that "RDF" is real RDF). Without consumability, we're wasting our time. 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
