Olivier, this is excellent feedback and I've heard many of the same concerns from others not directly involved in the workgroup. Thanks for taking the time to write this.
More comments below... On Wed, May 12, 2010 at 5:18 AM, Olivier Berger <[email protected]> wrote: > Pardon me in advance for that "rant"... It's just meant to help clarify > the current OSLC direction. Apologies in advance for the good people > investing efforts in OSLC... I'm just a devil's advocate. > > 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). > > In particular, I don't quite get it why one needs to reinvent the wheel > with shapes in OSLC when there's already ontologies as OWL to describe > resources on the Semantic Web... for instance. I'll defer here to Arthur's response, which I think is a very good one. > At least for the first half of the document references below, it isn't > clear. Now, when the format of the query results is described, it may > make more sense... but so hard to grasp at first sight ! We need more illustrative examples. Here's one that I wrote-up outside of the Core spec: http://open-services.net/bin/view/Main/OslcCoreQueryDiscussion Right now, our examples are confined to the representation in the appendices. This is probably not good enough. Do you have suggestions for places where examples would be most helpful? > I'm a bit afraid of too much over-specification for these > shapes/queries... whereas it isn't even clear if there's a single > consumer available somewhere (OK, I mean in the Open Source landscape) > that supports at least OSLC-CM V1 at the moment. This is an important concern and I'm going to propose that we postpone finalization beyond May 26 and wait to hear more from other workgroups as they adopt the Core spec and products as they implement the Core. > Ensuring OSLC becomes a standard (an Open one, I mean), means it may not > need to go too far and too fast, in particular in what concerns > over-specification for the core. I strongly believe bottom-up approaches > are interesting, and not so sure this is happening here now. Good point. I like the "rough consensus and working code" model and right now we are missing a lot of the working code part. > Pardon me if I haven't fully understood all that's happening (unability > to participate in conf calls certainly doesn't help much, and focusing > on coding (OAuth ATM) prevents me from reading all the docs in time), > but I fear there's some confusion between requirements for one > implementor's requirements design/specs, and specification of an open > standard, that should be at least a little bit understandable by the man > in the street. > > I'm doubtful it will be really easy to convince people to implement so > complex specs in existing tools, given the level of complexity I can > feel around here. > > Maybe a more KISS approach would be better until more feedback comes > from the grassroots implementors ? > > Hope this helps anyway ;) It does. I think we need to take steps to further simplify and to make the spec more understandable with examples. Thanks again from the write up. - Dave
