[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: regrep 9/29/2005: Comments on WSDL Profile for Reg/Rep
1. This profile assumes you have concrete WSDL and that may or may not apply. najmi: This may be a misunderstaning? A WSDL file may only contain PortType instances (or PortType and Binding) which the profile supports just fine. The profile assumes and suggests that there be 3 types of WSDL submitted: -XxInterface.wsdl: Containing PortTypes -XxBinding.wsdl: Containing Bindings -XxService.wsdl: Containing Services mm2: My point is you may or may not yet have the bindings. This is particularly true if you have only defined the abstract WSDL in the context of its relationship to an abstract process. 2. The cataloging, validation and discovery services are valuable, value-add services but may be better as a separate profile document. najmi: Why would a separate doc be better? I think for each domain specific use of registry there should be one profile which has separate chapters for each sub use case within the domain specific use (publish, validate, catalog, discover, subscribe). mm2: Suggest the group discuss the preferred approach. 3. I was uncertain if the cataloging service was dependent on the validation service as well. najmi: The ebRS spec says that validation service MUST be run *before* cataologing service so there is an implied dependency. I will try and make this clearer. mm2: Good idea. 4. There are some issues with WSDL, particularly using WSDL v1.1 that you should consider such as name overloading (and whether you constrain this to WS-I BP v1.1 that disallows this). najmi: This sounds significant though I do not understand it yet. Please provide details and specifics on this. What is the issue andhow can we address it? mm2: Names can be the same and whether this causes some issues with query and use, we may well discuss. Note: WSDL 1.1 explicitly supports operation overloading (section 2.5) although WS-I BP 1.1 eventually banned it (R2304). We discussed this at length in BPEL. 5. If an invocation control file is not used for the cataloguing service, what is the responsibility of the implementer? This raises the question if you have a MAY requirement and that capability is not provided, could any implementer hints be helpful in this profile? najmi: The invocation control file is optional in the ebRS spec and stays that way in this spec. I am not keen on providing implementation hints in this spec as this is a normative spec rather than a technical note. mm2: Then I would suggest that you say that when this invocation control file is not used, the responsibility falls to the implementer (i.e. is undefined). Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]