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] | [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]