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: HYPERLINK
"blocked::http://www.oracle.com/technology/tech/wireless/adf_mobile.html"http://www.oracle.com/technology/tech/wireless/adf_mobile.html
