[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What does SOAP really add?
> > > 2. I think of SOAP as glue for connecting scripting environments. Always > > have. You may think of SOAP as something else. I'm only now getting that > > this has been a source of disagreement, even with people we collaborated > > with. Often we don't patiently explore the assumptions others are making. It > > leads to disconnects. > > If SOAP were restricted to being a glue for scripting environments > nobody would complain about it. In fact I prefer XML-RPC in that role > but SOAP is okay. But I don't really see how the Google database (for > one example) or the UDDI repository can be considered "scripting > environments". If Google is a "scripting environment" then what isn't? > Oracle? > Paul, While the Database isn't, the Tools to access, update, change the database are. The same is true of Oracle, or ANY database for that matter. So the SOAP glue so to speak is the abstraction of those sql languages or other languages, (and I do agree that XML-RPC appears to be more suited to that call but it appears to only be tied to the HTTP protocol??)into a method based transaction. Hope that makes since. You said in another message, about the disconnects between the other XML standards. xslt, xinclude, etc. That and, XML Base, breaking namespaces and several other inconsistencies Led to my writing the message about the convoluted set of standards. And that it appears that Working Groups are not talking to each other. I am under the opinion. Fix what is broke now, even if that means invalidating some "backwards" compatibility. To ensure the longevity of the standards. A little about myself. I have worked in the Semiconductor industry for over 11 years. My industry Changes about 5 years. the standards move forward. In particular I worked in the capital equipment side of the industry. Most standards are based on a Corporate level, but we did have to work with the our competition in some standards. But on an internal side, sometimes, do to a lack of manpower, we would receive a box of parts, with no paperwork and told to do an upgrade. We would be the one that write the procedure for the install used for the rest of the company. Now those procedures were put in use by field sites, and modified. While a hardware install doesn't necessarily need to be backwards compatible,(once it is installed it normally doesn't have to be removed and it works) But the Base standards do need to work. Such things as which wire goes into which Terminal, the Voltage standards etc. are the base standards. And all of the XML languages don't have to interop. But I do believe that the base of the XML standards do. So my question is this, What are the base standards? XML defines the Meta Language for creating other languages. Xschema, Relax, DTD, (and whatever other flavors of document validation there are) define a validation for a Meta Language. Shouldn't these base languages be defined and made to work together. XML Base for example affects Namespaces But Namespaces doesn't appear to be upgradeing to take that in account. (out of fears of backwards capabilites) Soap has some of those issues. The Long diatribe on Namespaces in XSLT issues have also been discussed at great length. I do understand, needing the tools now. Believe me I don't like having to go back and redo work for trivial stuff, but in the long run it leads to a common Tool Set for all to use. and that any technician can work on. (we had tools built by hand(well I built a few of the very first tools, I would be called at all hours of the day and night for questions on that tool because it was a non standard tool compared to later tools that were built and modified from what we learned on the first 5 to 10 tools) Such thing as making componets moduliar to allow for customization based on a customer site. The first Tools were made to JUST work, which was fine to get into the market, Some basic underlying Standards were met, Voltage standards, etc, but the tool wasn't moduliar, it didn't allow for customization, (almost everything being hard wired) But in the long run later tools were not backwards compatable with earlier tools. The provided the same functions But to make the changes to it required alot of work and modification. XML while Young is retooling alot of what already exists. Some of that is necessary to introduce a level of abstraction. But in that retooling, the base needs to be firm. XML is still in the growing phase, and is missing some necessary parts to completely work. While those parts are being written, they break some of the underlying BASE standards. As in my example before, it took implementation to point out those weaknesses. And we had to break compatibility to fix some of those issues. I personally Believe that is where XML and other corresponding standards are at now. It is time to take a hard look at those standards and FIX those issues. Fix the BASE definitions: what standards must be implemented in higher stack standards what ones should etc. Some has stated that SOAP doesn't work with XSLT, and a few other standards. My question would be: Where in the standards does it say that it has to. Those are the rules that are missing and or not clearly defined. my thoughts Douglas
|
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
|