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
