OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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