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: Issue with the WSDL TN


Following yesterday's call, there is one technical issue, apart from the one
that led to CR-032, that Claus raised on the WSDL TN that has not, in my
opinion, been closed.

If anybody thinks that they have raised technical issues that have not been
addressed then speak now.

This issue is to do with the use of instanceParms in the instanceDetails
element of the tModelInstanceInfo that relates to the binding tModel.

Claus has suggested that we allow arbitrary content in this instanceParms
element in addition to the content required by the WSDL TN so that other
specifications etc. that want to build on the WSDL TN can add their own
content.

My view is that this whole tModelInstanceInfo is specific to the WSDL TN and
if other information needs to be supplied for a particular use of the WSDL
TN then that can be achieved by having another tModelInstanceInfo element
for some other tModel relevant to the application domain, or putting the
information in the WSDL itself using WSDL extensibility elements and using
the "WSDL Implementation Document" approach in the WSDL TN to allow the WSDL
to be retrieved and the information read from there.

If we allow particular uses of the WSDL TN to alter the content of the UDDI
artifacts required by the WSDL TN then we lose portability/interoperability.

It is also far from clear that overloading the single instanceParms element
will be sufficient given the limits on the length of it of 255 in UDDI V2
and even 8192 in UDDI V3.

John Colgrave
IBM





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