Hi, Charles, My comments in BLUE below.
Xinpeng Liu (David,刘昕鹏) Rational Quality Manager Development, IBM China Development Lab Tel:8610-82452825,Cell Phone:(+86)13520163713 Notes:Xin Peng Liu/China/IBM E-mail: [email protected] Fax: 8610-82451172 Address:3F, Ring Building, 28#, Zhongguancun Software Park, 8, Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 From: Charles Rankin <[email protected]> To: Jing Qian <[email protected]> Cc: [email protected] Date: 2012-07-03 07:39 Subject: Re: [Oslc-Automation] Implementation issues when Automation type is not known Sent by: [email protected] [email protected] wrote on 07/02/2012 04:09:41 PM: > From: Jing Qian/New Haven/IBM@IBMUS > [Snip] > Step2 - Set up the project areas associations > If the friend server is an automation provider that provides several > types of automation (build, test, provision, deployment...etc.), it > could be confusing for the user which one is for which. > > Here is an example, RQM is an automation service provider for both > test and provisioning, this could be in its rootservice.xml > > <jd:oslcCatalogs> > <oslc:ServiceProviderCatalog rdf:about="https://myserver1.ibm.com: > 9443/qm/auto/test/catalog"> > <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> > </oslc:ServiceProviderCatalog> > <oslc:ServiceProviderCatalog rdf:about="https://myserver1.ibm.com: > 9443/qm/auto/provision/catalog"> > <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> > </oslc:ServiceProviderCatalog> > </jd:oslcCatalogs> > > As you can see, <oslc:domain> for these 2 service providers are the > same, however, they just have different rdf:about URL, one is for > test automation, the other is for provision automation. > > But to the end user, when they have to choose the project area > association, all they see are 2 "Uses - Automation" choices, they > don't know which one is for which. > > The association would show 2 > "Uses - Automation" options, with no additional information to show > which one is for test, which one is for provisioning Along the lines of what David mentioned, if you are going to have two automation providers inside the same server instance, then you need some means to distinguish between them based on the registration information. I don't see directly how providing typing within the OSLC Automation spec will alleviate this issue. It will give a spec level standard way to achieve this, or we have to provide some customized properties to do it, but that will be provider specific. > Step3 - Using a picker to choose an Automation result > When programming this picker, it will need to be in the context of > some integration points, but if we don't know what type is the > automation association, how can we make sure we display the right content? > e.g. we need to bring up the UI picker to choose an automation > (test) result, but it could show a list of the automation result for > provisioning rather than for test. I would expect the picker to be a delegated UI, so the underlying service provider would be responsible for how to display / organize potential Automation Plans for selection. If the automation provider in question supports any form of Automation Plan typing, it would likely show up in this delegated UI. Yes, it is a great idea, and CLM link UIs are doing this, and the UI impl should be provider specific. But it still needs a standard way to provide such type source for UI to distill the info, that's why we think a type attribute is needed here. Charles Rankin_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
