[OSLC-CM] OSLC 1.0 interface

[Denis Tyrell]

Thanks Steve.  I'd like to see if we can get some of this into the 2.0 spec.  A goal we would have at Oracle is to be able to create a single connector that can connect to any 2.0 compliant repository and be able to discover the schema and constraints so that we can declaratively perform the actions we need without specific coding against any specific provider.
 
--- 
Denis Tyrell 
Senior Director, Server Technologies 
Oracle Corp 
Phone: (650) 506-0634 
Mobile: (925) 784-6915
Product Info:  HYPERLINK "blocked::http://www.oracle.com/technology/tech/wireless/adf_mobile.html"http://www.oracle.com/technology/tech/wireless/adf_mobile.html
 

  _____  

From: Steve K Speicher [mailto:sspeiche at us.ibm.com] 
Sent: Thursday, January 14, 2010 4:56 AM
To: Denis Tyrell
Cc: oslc-cm at open-services.net
Subject: Re: [OSLC-CM] OSLC 1.0 interface



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/36c399ca/attachment-0003.html>