In CM 1.0, we had only stated: "Typical configurations should not need more than 2 levels of configuration context, so a limit of 5 is recommended. "
I hadn't considered adding this in CM 2.0 spec but could. We had kicked around an "implementation guide" to accompany the spec, which may a good candidate for something like this. Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 > From: Andrew J Berner/Dallas/IBM@IBMUS > To: Dave <[email protected]> > Cc: oslc-core <[email protected]>, oslc-core-bounces@open- > services.net > Date: 07/12/2010 04:58 PM > Subject: Re: [oslc-core] Discovery document hierarchy should be > constant length per provider? > Sent by: [email protected] > > 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 > [email protected] > > Ready for IBM Rational software partner program - > http://www.ibm.com/isv/rational/readyfor.html > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
