[
Lists Home |
Date Index |
Thread Index
]
>
> > 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
|
