[oslc-core] Discovery document hierarchy should be constant length per provider?

[Andrew J Berner]

The OSLC specs on purpose do not specify the "method of discover" for a
provider, leaving it up to the provider to deal with differences in their
basic data structures.  Also, I believe we have a general principle (not
sure if this is written down though!) that URL's for service calls should
be discovered rather than either cached or constructed from "smart keys".

For some of the specs, that's working just fine:  The CM spec
implementations do discovery differently, because, for example, ClearQuest
"user databases" are in a different structure from RTC "project areas".
But for each one, there's a fixed path you take.

In some discussions around RM tools (my exposure to these discussions has
been around implmenetation rather than in the spec workgroup so far), a
complication has arisen.  Some tools have hierarchical "folder like"
structures.  And the folders in that hierarchy change dynamically of
course.  When you have a Factory URL, since the created requirement must be
put into a folder, the question comes up of what the "discovery" structure
should be.  One possibility, that I think is a problem but is very
tempting, is to have a hierarchy of discovery documents:  You start with a
top level, which gives the URL of the discovery document (note I'm not
saying "service document" vs. "catalog"---let's lump them all together as
"discovery document"), which gives the URLs for the multiple "project
discovery documents" based on whatever projects are currently available
(similar to the CM ones); a project discover document gives the URL's of
the multiple "folder discovery documents"---and a folder discovery document
has several things, perhaps:  URL's for the factories to create resources
in that folder, and URL's for subfolder discovery documents.  You then
recursively go down the folder hierarchy discovering the urls of discovery
documents till you get to the one you want, and then get the URL of the
factory.

I believe this is taking "discovery" too far.  In practice, if this is
what's being done, we'll find that the "opaque urls" probably in fact are
constructed in some way from the "url for the folder" (even if that folder
isn't yet exposed as a resource!!!) and that URL of the folder is
permanent, just like it was a resource.

I think there should be a spec around this, and that "discovery" should
have a constant length hierarchy for any provider, and not require
recursive search just to get the call you want to make.  Then we won't
tempt consumers to start caching the URL's instead of that recursive
search.

Comments?

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html