[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] WSDL TN comments
Paul, Thanks for taking the time to review the TN. Line 336: Agreed, but the point is that if you do require the information you have to get it from somewhere other than UDDI. Line 346: I am not sure what you think the reference should be to. These keys are actually both evolved and derived depending on your point of view so I have removed the reference to evolved keys. Line 374: I have changed the text and hopefully made it clearer. Line 420: I have changed the footnote and hopefully made it clearer. I do not want this TN to attempt to be a TN/BP on writing WSDL in general, although I think such a document would be useful, and in part is addressed by what WS-I are doing. I think it is important that the TN support any valid WSDL, so as long as it is valid to omit a targetNamespace then we should support that and define what it means, and I think the absence of a namespace keyedReference is appropriate. I agree with you about a separate TN/BP on the generic XML stuff but I do not want to delay this TN further to establish such a dependency. If we do want to have a separate XML TN/BP then the current generic XML content in the WSDL TN can move to that and a future WSDL TN/BP can refer to the XML TN/BP as appropriate. The various things that are broken because the document and tModels have not yet been published will hopefully be sorted out as part of the final publication process, once the TC agrees to publish the TN. John Colgrave IBM -----Original Message----- From: Paul Denning [mailto:pauld@mitre.org] Sent: 09 April 2003 17:56 To: uddi-spec@lists.oasis-open.org Subject: [uddi-spec] WSDL TN comments Line 336. Must go out of UDDI ... may not be necessary at runtime. At design time you expect to go out of UDDI to retrieve WSDL and possibly other artifacts needed for development of services or consumers. You may not need to retrieve WSDL at runtime if the UDDI binding has the accessPoint and you are not doing any dynamic wsdl2java code generation at runtime. Line 346. "Evolved keys" should have a reference to ... Line 374. determined from metadata in categoryBag - needs more explanation, at least a statement like " as described below". Line 420. First line of footnote is confusing. You want to be clear that targetNamespace SHOULD be used in WSDL files. Also, TN should state that it does not apply to WSDL without targetNamespace, and that automatic registration MUST fail if the WSDL file does not contain a targetNamespace. Or perhaps require the keyValue (line 419) to be a well-known URI that means "null"; i.e., no targetNamespace. (need a well-known URI like /dev/null; should get w3c to define it so everyone can use it, rather than have a Null URI for UDDI, and a different URI with same semantics defined by OASIS, IETF, ...). Recommend a separate TN/BP to describe the XML Namespace tModel (i.e., where keyValue is a namespace URI) because it is more generally useful than just WSDL mapping. Line 919. overviewURL is broken (TN not yet published). Lines 961, 1013.. tModelKey not yet published to UBR. (not yet done reading the draft TN, but wanted to get these out in case I don't get back to it soon). Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]