[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [uddi-spec] New UDDI/WSDL Technical Note
Joel, Thank you for your comments. I apologise for omitting line numbers. I have attached a new version to this note which has the changes in response to your comments and which has line numbers turned on. I have added responses to your points below. John ----- Original Message ----- [Introductory text deleted.] > at the bottom of page 9 and with specific details additionally noted within > footnote 3, you state that the new [UDDI]businessService MAY be named the > same as the [WSDL]Service. within the footnote you state that this may in > fact cause problems. there is specific mention of the name of the service > within the [UDDI]categoryBag. could you be a little more clear here, rather > than state what you MAY do and what problems this may cause, please restate > this in terms of RECOMMENDED practice. for instance, what would a > practitioner do, if it encountered scenarios, A, B, C, or D... and then > state clearly which combination of values and uses is preferred. The issue is to do with extracting the WSDL service name from the businessService. In the case of an existing businessService, the businessService name is unlikely to match the WSDL service name. I have changed the text to say that when a new businessService is created, its name MUST be the WSDL service name and I have changed the footnote to say that if you want to retrieve the WSDL service name you must use the keyedReference and not the businessService name. > with respect to modeling against uddi v2, within section 2.5.4, where you > state that the tModelInstanceInfo must contain required local name within > the instanceParms, what do the instanceParms look like? please show an > example of these somewhere. would it help to include the target namespace > within the instanceParms as well? why isn't this information (local name > and/or namespace) required in the UDDI V3 modeling (ref 2.6.4)? ah, i just > my answer to this last question in footnote 5. The instanceParms are shown in the example, see line 531. :-) The namespace must be the namespace of the enclosing service. We have tried to minimise the duplication of information. > for the v2 examples shown within section 3.2.x, would it more illustrative > to show the keyName's within the keyedReference elements rather than just > the cryptic UUID values. are these going to be created and loaded as > standard tModel's for all to use? The keyNames are not relevant. Can you expand a little on what you mean? It is assumed that the tModels in Appendix A are going to be published to the V2 UBR. See section 1.3. > when listing examples of tModelKey's for use within UDDI V3, should we show > human readable keys vs. the rather cryptic UUID values? ref: section, > 3.4.x, 3.5.x, and V3 format keys within the appendices. Given the assumption that the tModels are going to be published in the V2 UBR, the V3 keys will be migrated within a Root Registry as per 10.1.3 of the UDDI V3 spec. As such, they will remain cryptic UUID values I am afraid. > could you clarify the use as defined in Appendix B as recommended or at > least highlight some opportunities for that usage. in other words, when > would I want to use (XPointer-based) fragments? what are costs and benefits > of this use? There was a hint about this but I agree it was not clear. I have added some text to Appendix B. The preferred approach is that applications use the UDDI metadata to interpret the URL but if you want to use some generic software that is not written to understand categoryBags etc. you need to encode all of the information in a standard way into the URL itself, which is where XPointer comes in. > minor nit picks. within A.5, the word Definition should be formatted as a > header and labeled as A.5.2 to be consistent with the other canonical tModel > definitions. the opening element name within almost all of the example code > is not bolded and does not match in format with the remainder of the > example. (hey, i said these were minor didn't i?) Sorted. I said up front the formatting was in a mess. There is still work to do on the formatting. [My original note deleted.]
Attachment:
wsdl-TN-V2.00-Draft-20020926.pdf
Description: Adobe PDF document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC