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

[Steve K Speicher]

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 at IBMUS
> To: Dave <snoopdave at gmail.com>
> Cc: oslc-core <oslc-core at open-services.net>, oslc-core-bounces at 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: oslc-core-bounces at open-services.net
> 
> 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
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net