regrep 9/29/2005: Comments on WSDL Profile for Reg/Rep

[Monica J Martin <Monica.Martin@Sun.COM>]

  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.