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


Karsten, John,

Well done.  This looks very good and has matured nicely from earlier
versions that we discussed this summer.  For future reviews, it may be very
helpful to retain line numbers so that reviewers can be very specific with
their comments.  

Here are a few simple questions/comments:

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.

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.

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?

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.

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?

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?)

joel


-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Tuesday, September 24, 2002 5:23 AM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] New UDDI/WSDL Technical Note


Attached is a draft of the new UDDI/WSDL Technical Note that I mentioned
during the conference call.

It needs some editorial work and I have messed up the formatting in
switching to a new template but I think the technical content is sound.

I have not yet read Anne's comments (I wanted to get the current draft out
to the committee as soon as possible) but I will take a look at them now and
respond shortly.

Please send any comments to this list.

John Colgrave
IBM


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC