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

["Daniel Feygin" <feygin@unitspace.com>]

John,

Thanks for the clarification.  Your point makes more sense now, although I
don't accept it entirely.

I would like to focus on the only relevant part of our argument - the
conclusion, which we seem to agree on anyhow.

Daniel


> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
> Sent: Monday, June 02, 2003 6:00 PM
> To: 'Daniel Feygin'; 'Von Riegen, Claus'; 
> uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Issue with the WSDL TN
> 
> 
> Daniel,
> 
> I think you have come to the right conclusion so I won't 
> belabour the point too much, but I will just point out a 
> couple of issues.
> 
> What if one tool decided that wsdl:port should be at the 
> beginning of the string and another decided it should be at the end?
> 
> Assuming the strings in Claus's example are typical, there 
> would be space for three extra name-value pairs to be added 
> to the instanceParms in V2. However, if only one of the 
> strings was one character longer then there would only be 
> space for two.  What is the third application that wants to 
> extend instanceParms to do in this case?
> 
> John Colgrave
> IBM
> 
> 
> -----Original Message-----
> From: Daniel Feygin [mailto:feygin@unitspace.com] 
> Sent: 29 May 2003 08:33
> To: 'Von Riegen, Claus'; 'John Colgrave'; 
> uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Issue with the WSDL TN
> 
> I fail to see John's point that adding arbitrary name-value 
> pairs to WSDL tModelInstanceInfo instanceParms would hamper 
> portability/interoperability. If tools vendors know to expect 
> such extra parameters, they will know to ignore them and only 
> look for the ones that matter to their tool.
> 
> However I don't see why these extra parameters couldn't go 
> into a separate tModelInstanceInfo corresponding to a 
> different tModel.  This other tModelInstanceInfo would be a 
> part of the same bindingTemplate and therefore would 
> constitute a part of its technical fingerprint.  I don't 
> perceive Claus's direction as digressive, but I don't see a 
> compelling reason to adopt this proposal.
> 
> If no such compelling reason exists (I'm not aware of any at 
> this time), I would object having arbitrary parameters in 
> WSDL tModelInstanceInfo instanceParms on the grounds that 
> this supports, and thereby fosters, poor registration 
> modeling decisions on the part of developers publishing to 
> UDDI.  Because these decisions would affect individuals other 
> than the publishers, we should strive to improve the affected 
> users' experience with UDDI by making publishers conform to 
> 'good' practices.  Requiring separate tModels to represent 
> different concepts would enable better communication between 
> service provider and service consumer by imposing one such 
> good practice on the publisher.
> 
> Daniel
> 
> 
> > -----Original Message-----
> > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > Sent: Wednesday, May 28, 2003 7:41 PM
> > 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-acco
> unt="http://www.example.com/webservices/useracco> unt"</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


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