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

[Andrew J Berner]

Dave said in reply to my previous note:

I think I understand the issue, Andy. Two observations:

1 - Looking at the current round of Core-based specs coming along: CM,
RM and QM, I see that they leave the service-nesting structure of the
service provider docs up to the implementation.

2 - I've been assuming that products have such different service
nesting, project/folder requirements that this was an areas where we
cannot set a standard structure or depth.

Dave, I understand those two observations.  For example, one service
provider may require you to go "three deep" before you get to a creation
factory, but another service provider may require you to only go "two
deep".  That fits your observations, and I suspect is necessary for the
reasons you say, even though it does have the consequence that a consumer
probably has to write different code for those two providers up to the
point of getting the factory URL.

But I was asking about something a bit different.  This would be aprovider
of some domain spec where the nesting strategy is, for that provider,
arbitrarily long, because each folder in a hierarchy has it's own service
document that can only be discovered by recursively going down a hierarchy
of service documents that parallels the hierarchy of the folders
themselves.  I don't think this is an issue in any of the current specs yet
(and if it is, it's not how they do it), but it's coming up in some other
discussions that probably eventually will show up in future versions of
some of the domain specs.

It will start to become awfully tempting to tease out a "URL pattern" and
construct the URL from known pieces rather than discovering it if that's
done, and I don't think that's a good idea.

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