[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] WSDL TN Review: feedback on the current TN
Sam, Thank you, as always, for your comments. I have not distinguished between Content and Editorial in my responses. UDDI V3 Optional Extensions We decided they should be optional because we felt it was more important to have a single mapping that could be used via either the UDDI V2 API or the UDDI V3 API. What people can rely on is that the same queries will be available via either V2 or V3. To address both requirements would require the port name to appear twice, and we have tried to avoid duplicate information wherever possible. We rejected having just the categoryBag way of storing the name as this would be invisible to applications using the V2 API. This area is certainly something we can consider again in the light of implementation experience. Mapping of Local Names This was discussed several times. A name is a name and the obvious mapping is to map the WSDL entity name to the corresponding UDDI entity name. The only places where this is not done is where either the UDDI entity concerned does not have a name or it may already exist with a name that we do not want to change. The current mapping represents the best we thought we could do given the constraints of the UDDI V2 structures. I don't think the name is a suitable categorization but if we did use the categoryBag wherever we could we would still have to come up with a name for the various tModels, and it is not clear that there is any better name than the name of the corresponding WSDL entity, in which case we simply have a more complex mapping with duplicated information, which again we wanted to avoid. V2 find_binding Examples This is a good catch. I had already spotted it and made the necessary changes, which were more than editorial as they affect the queries that you have to do. V3 Examples I think that in light of the previous point, it is worth considering this. I am not sure if we can make much use of embedded queries but I will look at the V3 version of each of the sample V2 queries that we have and if there is a significant benefit in doing the V3 query differently then I will add a "Sample V3 Queries" section with those example queries where it makes sense. John Colgrave IBM -----Original Message----- From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com] Sent: 08 April 2003 01:57 To: John Colgrave Cc: uddi-spec@lists.oasis-open.org Subject: Re: [uddi-spec] WSDL TN Review: feedback on the current TN 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]