Re: [uddi-spec] WSDL TN Review: feedback on the current TN

[Wai-Kwong Sam LEE <Sam.Lee@oracle.com>]

John and others,

Thanks for great work of the well-polished TN! I've got a few comments:

Content
--------
- UDDIv3 optional extensions (Section 2.5.2): should they remain 
optional? Leaving them optional makes the users (of a v3 registry) hard 
to decide whether to rely on them or not. For example, if a user wants 
to find binding with a particular port name, he does not know whether he 
  can rely on doing a find_binding by categoryBag or not.


- Mapping of various wsdl: local names: I believe it had been discussed 
for a while in the past and I do not intend to reopen a rat hole. 
Anyhow, in brief, in the current mapping:
wsdl:portType – tModel name
wsdl:binding – tModel name
wsdl:port – bindingTemplate instanceParms; optionally bindingTemplate 
categoryBag (in UDDIv3)
wsdl:service – businessService categoryBag; optionally businessService name

It seems that we can also choose to more uniformly (i.e., easier to 
understand) map all wsdl: local names to categoryBag (with the exception 
of wsdl:port in UDDIv2 case).  The similar constructs (wsdl namespace) 
are also uniformly mapped to categoryBag.
I believe there must be some reason that the sub-committee chose not to 
do so. It'd be great if someone could explain the motivation of the 
current mapping.



Editorial
----------

- In find_binding examples (section 3.3.3 and 3.3.4), there is no 
serviceKey attribute. However, in UDDIv2 serviceKey attribute is required.

- It’d be great if some examples can be given demonstrate the capability 
added in the UDDIv3 mapping. For example, an example “Find bindings for 
port name” can be given to demonstrate the use of categoryBag in 
bindingTemplate.
Furthermore, some examples can also take advantage of basic UDDIv3 
enhancements. For example, section 3.3.3 can demonstrate the use of 
find_binding without serviceKey; section 3.3.5 can demonstrate embedded 
queries.


- sam