RE: [uddi-spec] Issue with the WSDL TN

["John Colgrave" <colgrave@hursley.ibm.com>]

Claus,

That is what you get for letting me describe your issue. :-)

Obviously, my comments were in response to this name=value approach, even
though I did not describe it very well.

The tModelInstanceInfo required by the WSDL TN represents the wsdl:port
element. The only attributes of a wsdl:port are the name of the port and the
binding the port implements.  The name goes into the instanceParms of the
tModelInstanceInfo and the binding determines the tModelKey of the
tModelInstanceInfo.  If there is any extra information in the WSDL,
extensibility elements for either the port or the binding, then that
information should be retrieved from the WSDL.  If there is any other
information that does not relate to the WSDL then that should be captured in
other tModelInstanceInfos.

John Colgrave
IBM


-----Original Message-----
From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] 
Sent: 28 May 2003 16:41
To: 'John Colgrave'; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Issue with the WSDL TN

What I actually suggested was the ability to add additional data in the form
of name-value pairs, separated by semicolons.
For example, if one wants to express an implementation detail about a
(propietary) procedure that is necessary to get a user account in the system
that implements the Web service, the instanceParms within a bindingTemplate
(that represents a wsdl:port) could look as follows:

<instanceParms>wsdl:port="the-port-name";example.com:user-account="http://ww
w.example.com/webservices/useraccount"</instanceParms>
 
Tools then would look for the "wsdl:port" name within the instanceParms and
could still automatically retrieve the corresponding name value.

Note that this approach would be necessary (at least in V2) if one wants to
avoid the publication of such (propietary) tModels since bindingTemplates
don't carry a categoryBag (in V3 a keyedReference using the general_keywords
category system would work, although it would then not be part of the
"technical fingerprint", i.e. the set of tModelInstanceInfos).

I know that there is a trade-off between this flexible, but more complex
approach and the limited, but simpler approach that is currently specified
in the TN. I'd be happy to drop the proposal if the TC tells me that my
proposed direction is too digressive.

Claus

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
Sent: Mittwoch, 28. Mai 2003 15:59
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] 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




You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php

You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php