Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to L
 > From: Champion, Mike [mailto:Mike.Champion@S...] <snip/> > Also sprach Edd: 'Following the standard YAP pattern, acronyms and > consortia > followed: DISCO, WSDL, UDDI. Suddenly we're in the middle of a new > wave of technology, another set of features, and nobody really seems > to have asked, to say nothing of answered sensibly, the question: "Uh, > what do I need this for?"' > > In other words, Edd's critique (as I interpret it) is that > "standards" were > proposed to solve problems before they were understood, and > people jumped on > the bandwagon for these "standards" simply because everyone > else was. I guess I'm looking at it a bit differently. I don't see DISCO, WSDL, or UDDI as standards. They are open specifications being developed and pursued outside of standards bodies as the parties involved try to understand the problems better and validate that these proposals offer solutions of real value. True, there is much marketing hype around them. But I think that's difficult to avoid when you have these things being proposed and developed in a very public fashion by vendors that are not only collaborating on these technologies, but also competing with each other for developer mindshare. > If there is a real need for machine-readable calling > information, maybe RDDL > or something like it could be leveraged. That would be cool, although there are some gaps that would need to be filled going this route. However, I would think an XLink-based mechanism could conceivably be developed that could do everything WSDL does (at the cost of far greater abstraction and generality that is likely to create a steeper learning curve for developers not already versed in XLink). > Or if WSDL needs to be invented, > base it on concrete experience rather than conjecture about > what people might possibly need someday. WSDL was motivated by concrete experience with early SOAP implementations. For those who tried to develop tools that supported creating client side interfaces that map to a specific service -- as any developer using CORBA, EJBs, or COM is accustomed to -- it was clear that something like this was needed. For the business developer who wants to write code dealing with PurchaseOrders, Invoices, InventoryItems, etc., this offers obvious benefits. Forgoing such domain-specific classes/structs/interfaces (or whatever) in favor of generic DOM structures means less productivity, more bugs, and no business benefit. That is a retrograde step. Forgoing these domain-specific constructs in favor of dealing with DOM APIs to model this information is like tossing away power tools in favor of the stone axe. That's what's driving WSDL. As web services mature, very few programmers using web services tools will be dealing with XML APIs (unless they want to). 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
