[OSLC-CM] OSLC 1.0 interface

[Steve K Speicher]

Also to note, some CM providers have extended the specification to include 
schema information (for example by providing a reference to it from the 
service description document). 

Steve K Speicher/Raleigh/IBM wrote on 01/14/2010 07:56:09 AM:
> 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/4a0db91d/attachment-0003.html>