[OSLC-CM] OSLC 1.0 interface

[Steve K Speicher]

Hi Denis,

Thanks for the feedback.  OSLC CM 1.0 supports a loosely-couple delegated 
approach to integration, providing "just enough" specification 
capabilities to provide an integration experience.  Taking this approach, 
we did not provide a schema story for the use cases you described. 
Instead, we provided a way for CM providers to expose their Web UI 
creation dialogs for delegated change request creation as well as a 
factory for programmatic creation.  This way, a CM provider can expose and 
enforce its own rules around creation of change requests.

For consumers of the 1.0 specification who need to know more details about 
rules for creating change requests and understanding details of the 
schema, have to depend on a method not defined in the specification.

There is still quite a bit of value in supporting the 1.0 spec in that you 
have a consistent model for service discovery.  You can leverage Web UI 
delegated dialogs where appropriate.  Once you have schema information, 
you can consistently access the CM resources by using 1.0 features of: 
creation, query, selective retrieval, selective updates, etc.

These use cases you identify are good input into future specification 
efforts.   There are many complexities in exposing the schema, rules and 
constraints that are needed to be satisfied by support some of the 
advanced capabilities in today's CM providers.   I'm confident that this 
WG can find a workable solution in a near future specification.

Regards,
Steve Speicher | IBM Rational Software | (919) 254-0645


Denis Tyrell <DENIS.TYRELL at oracle.com> wrote on 01/13/2010 03:23:19 PM:

> We're currently trying to create an OSLC CM 1.0 connector that will 
> be able to connect to any 1.0 compliant CM provider.  We're 
> encountering some issues that I'd like to bring up and see if there 
> are solutions or if we're just doing things incorrectly.  If there 
> are limitations currently, we want to make sure we talk about this 
> in relation to the 2.0 spec.
> 
> 1)  We know the list of OSLC 1.0 CM base properties from the spec. 
> There is no way to discover extended properties that a particular 
> provider adds.  Parsing the XML for every namespace is too tedious 
> because of the heirarchical nature of the XML.
> Use case:  Priority is not part of the 1.0 spec but Rational Team 
> Concert has this field and exposes it in their 1.0 spec.  We'd like 
> users using our connector to be able to update the RTC Priority 
> property but there is no way for our connector to discover it 
> generically without specifically coding for RTC.  If another 
> repository exposes Priority differently, we'd like to be able 
> discover that and any other extended attributes they provide.
> Use case:  To create an RTC CM, the "FiledAgainst" property is 
> required but there is no way for a connector to know this 
> generically and would be forced to create a specific connector for 
> RTC.  We need this to be discoverable.
> 
> 2)  We need to know the schema of the underlying property values. 
> Use case:  Owner could be an extended property of a provider 
> supporting the 1.0 spec.  Owner might have an underlying schema like
> First Name, Last Name, Email, ID.  If we have a URL that will give 
> us values for the Owner field and we can query on it, we need to 
> know the schema up front and be able to discover it.  Thus we can 
> provide a nice UI to show the LOV results with columned data and 
> query results.
> 
> 
> 
> --- 
> Denis Tyrell 
> Senior Director, Server Technologies 
> Oracle Corp 
> Phone: (650) 506-0634 
> Mobile: (925) 784-6915
> Product Info:  
http://www.oracle.com/technology/tech/wireless/adf_mobile.html
> 
> _______________________________________________
> OSLC-CM mailing list
> OSLC-CM at open-services.net
> http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20100114/6a76c2ea/attachment-0003.html>