Le lundi 23 novembre 2009 à 08:47 -0500, Steve K Speicher a écrit : >
> To be clear, implementations can always support more than what the > spec states and still be conforming. The intent of having the defined > content types is so that consumers can depend on a minimal set, yet > discover (content negotiation) any additional ones that are > supported. > Good. > > Still, that may be a first step towards OSLC-CM read-only support > that > > may help get feedback from the field. > > > > Any comments ? > > > > As we try to be very scenario driven, I think it would help the > understanding of the value of what you are doing if you could > illustrate it with some scenarios. Showing what is possible with this > approach, that may not have been with previous ones. > I was merely thinking of a way to give a hint to people of what could easily be done for them to move closer to supporting an OSLC-CM like (read-only) API on their servers, should their tools not yet support OSLC-CM. I.e. by installing a set of triplify mappings on a bugzilla, one could very easily provide an almost valid way to query the Change_Request RDF descriptions of all their bugs... until someone hacks the real OSLC-CM V1 plugin for Bugzilla. (btw, we have something like a triplify config for bugzilla in our public SVN that could be adapted to limit itself to OSLC-CM V1 DC terms very easily) > Overall I sounds very valuable and complimentary. Thanks ;) Regards. -- Olivier BERGER <[email protected]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
