W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

RE: help with incorporating operation name v3 proposal (issue 168)

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Wed, 28 Jul 2004 11:59:45 -0700
Message-ID: <DD35CC66F54D8248B6E04232892B633802D8B45B@RED-MSG-43.redmond.corp.microsoft.com>
To: "Umit Yalcinalp" <umit.yalcinalp@oracle.com>, "Amelia A Lewis" <alewis@tibco.com>
Cc: "Glen Daniels" <gdaniels@sonicsoftware.com>, <dorchard@bea.com>, <www-ws-desc@w3.org>
Umit,
 
You said "No, it is the other way around. If you declare that you have
some magical secret souce that you deliver the requirement, and I don't
know about it, I can not interoperate with you. At least, the secret
souce is declared in WSDL, no longer secret albeit,  more interop. ;-) "

The point is that there is no secret souce[sic]. My service will work
just fine when you send me messages with just a soap:Body as described
in the interface definition. I don't need any magic headers or anything
like that to determine the operation. So you requiring me to put a
feature in my WSDL, which you won't support, leads to LESS interop, not
more.
 
Gudge


________________________________

	From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org] On Behalf Of Umit Yalcinalp
	Sent: 28 July 2004 19:27
	To: Amelia A Lewis
	Cc: Glen Daniels; dorchard@bea.com; www-ws-desc@w3.org
	Subject: Re: help with incorporating operation name v3 proposal
(issue 168)
	
	


	Amelia A Lewis wrote:
	

		On Tue, 27 Jul 2004 18:41:16 -0400
		Glen Daniels <gdaniels@sonicsoftware.com>
<mailto:gdaniels@sonicsoftware.com>  wrote:
		  

			I'm not sure I understand what you think is
"absurd" here.  We are
			    

		
		Creating a feature which, in toto, reads "This feature,
identified by the
		URI http://www.example.org/alkahest/, fulfills the
requirement of being a
		required extension."
		
		And this *will* happen, because in the case under
discussion (which we
		shouldn't be spending time on now, since it's already
been voted on, and I
		lost), at least two companies that I know of will
document how to sidestep
		the Stupid Requirement.  

	Well, as they say sticks and stones ...
	

		Since all that a processor can tell, looking at
		the thing, is that it contains or does not contain an
extension which is
		marked wsdl:required, that's all that can be tested.  If
that's missing,
		the processor can say "missing required extension," but
can't identify the
		extension that's required.  Something is required to be
required.  
		
		We encounter a great many companies who want to describe
existing legacy
		services, which may not, in the first pass of
modernization, actually use
		a reasonable dispatch mechanism.  They have to put
*something* there.  So
		they will.

	That is fine. The other companies that try to interoperate with
them will see the "something" in the WSDL, and decide whether they can 
	comply with it, precisely whether that "Something" requires them
to do something, put additional things on the envelope, etc. 
	

		
		*shrug*  Clearly, that's an optional extension.  Only it
isn't, it's
		required.
		
		What's absurd is for the Description language to make a
Prescription for
		best practice.  A recommendation, fine.  A requirement?
Just means less
		interop.  Why bother defining the algorithm you use to
dispatch, when you
		can just plug in Meaningless Feature to fulfill Stupid
Requirement?
		  

	No, it is the other way around. If you declare that you have
some magical secret souce that you deliver the requirement, and I don't
know about it, I can not interoperate with you. At least, the secret
souce is declared in WSDL, no longer secret albeit,  more interop. ;-) 
	

		dadadadadadadadadadadadadadadadadadadadadadadadadadada
dada
		  

		Amy!
		  

	Cheers, 
	
	--umit
	
	
	-- 
	Umit Yalcinalp                                  
	Consulting Member of Technical Staff
	ORACLE
	Phone: +1 650 607 6154                          
	Email: umit.yalcinalp@oracle.com
	
Received on Wednesday, 28 July 2004 15:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT