[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] some editorial comments on the UDDI-WSDL TN
Sam, Thanks, as always, for your comments. I have incorporated all of them except the one relating to footnote 3 into the version that I have sent to the co-chairs and which will hopefully go to vote soon. I was keen from the outset that we not try and produce a best practice for how to write WSDL in general but I think this footnote is reasonable as it speaks about a different set of assumptions around what a service is between UDDI and WSDL in general. John Colgrave IBM -----Original Message----- From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com] Sent: 18 June 2003 20:54 To: John Colgrave; uddi-spec@lists.oasis-open.org Subject: [uddi-spec] some editorial comments on the UDDI-WSDL TN John, I took a pass on the latest revision you sent to me. The following is some collective editorial feedback based on the latest revision: 1.1 Goals and Requirements ================================ line 188-189: It'd be good if we also mention discovery on the businessService level in the motivation. For example: Given the namespace and/or local name of a wsdl:service, find the businessService that represents that service. Footnote 3 in Section 2.4.3 wsdl:service -> uddi:businessService ================================================================== (I believe it was discussed before but I did not recall the decision.) The statement in footnote 3, while I (and many people) do agree, is somewhat out-of-scope (it's strictly a wsdl modeling issue) and may not be appropriate. If it's been determined that we should still have the statement, that's fine (not a show stopper). tModel XML snippets in Section 3 ================================== The tModel XML snippets do not follow uddi schema: The overviewDoc should appear before categoryBag. Example: the portType tModel in 3.2.1 B.7 Protocol Categorization (and B.8 Transport Categorization) =============================================================== It'd be good to further specify what it means by "tModel that represents a protocol": tModels classified as protocol in uddi-org:types categorization scheme. Suggested revised text: Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the tModel that represents a protocol. The protocol tModel SHOULD be classified as "protocol" in the uddi-org:types categorization scheme. A similar clarification could be made in transport: Valid values for this category system are tModelKeys. The content of the keyValue attribute in a keyedReference that refers to this tModel is the tModelKey of the tModel that represents a transport. The transport tModel SHOULD be classified as "transport" in the uddi-org:types categorization scheme. - sam You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro up.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]