[
Lists Home |
Date Index |
Thread Index
]
As I remember it, XML hype built on the back of the resounding success
of HTML for the web. In terms of timing and mindshare, XML rode a wave
that CORBA couldn't catch.
Which raises a possibly even more critical point: if you want to
compare XML to CORBA or c structs for the exchange of application data
between apps, go ahead and argue. But if you want to assert that c
structs or CORBA are in any way suitable for representing documents the
way XML is, I think you'll just get laughed at.
But XML is used by reasoning people (and applications) both to represent
documents AND to exchange data between applications. Apart from XML's
suitability for either case in its own right, there are a lot of really
compelling cases where the same information needs to be used both ways.
--->N
> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: Friday, September 16, 2005 9:08 AM
> To: 'Anil Philip'; 'xml dev'
> Subject: RE: [xml-dev] basic qs - how is xml more flexible
> for exchanging data?
>
> > My point had little to do with 'C'. I used it as a
> > point to be as basic as possible. To be more rigorous
> > I should have said Corba instead of 'C' and 'idl
> > struct' instead of 'C struct'.
>
> You should indeed, that changes the argument completely!
> Corba is a protocol
> with an associated language IDL. C is a language with no associated
> protocol. Corba/IDL is a viable way of exchanging data
> between distributed
> applications, C structs are not.
>
> So why has XML been more successful for this purpose than
> Corba? Partly
> commercial factors - the Corba environments I knew about were
> very pricey.
> This also accounts for the failure of ASN.1 to hit the big
> time. Partly for
> the reasons you outline below: XML has more flexibility for
> the different
> parties involved to make changes without all having to
> synchronize their
> upgrades. Partly because XML works over a wider variety of transports,
> synchronous and asynchronous; partly because different suppliers' XML
> implementations do actually interoperate whereas different
> suppliers' CORBA
> implementations often don't; partly because of Unicode;
> partly because when
> you get problems with a message you can look at it in a cheap
> text editor
> and understand what's wrong; ...
>
> Are any more reasons needed?
>
> Michael Kay
> http://www.saxonica.com/
>
> > My point: For example in Corba, when an idl struct or
> > interface changes, then it is a major headache - every
> > client of the server has to be updated. At the very
> > least they must recompile their stubs and redeploy
> > their applications with the new idl interface in the
> > case if a new method is added with no other changes to
> > the interface; if the struct changed - say a new field
> > was added (not a modification or deletion which would
> > understandably affect everyone), then the server must
> > continue supporting the old struct as well as the new
> > one. For clients that want to stay with the old struct
> > (avoiding client code changes which they might not
> > need) the old servants must coexist with the new
> > servants in the server. I have seen this in practice
> > when the wireless telecom I worked at previously -
> > their Corba server had several independent wireless
> > resellers use it to exchange data. There was a good
> > deal of duplication in code and work and resources.
> > This is what I understand by tight coupling - which
> > reduces maintainability.
> > I thought that XML promoted loose coupling and
> > flexibility. I wondered if it was really so.
> > Additionally you now have the 'feature' of parsing of
> > tags and also type-conversion to get at the data.
> > thanks,
> > Anil Philip
> > ----
> >
> >
> > for good news go to
> > http://members.tripod.com/~goodnewsforyou/goodnews.html
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
> >
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
