[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: basic qs - how is xml more flexible for exchanging data?

• To: "'Anil Philip'" <goodnewsforyou@y...>,"'xml dev'" <xml-dev@l...>
• Subject: RE: basic qs - how is xml more flexible for exchanging data?
• From: "Michael Kay" <mike@s...>
• Date: Fri, 16 Sep 2005 17:08:03 +0100
• In-reply-to: <20050916151458.48565.qmail@w...>
• Thread-index: AcW60WVGf48j7a3BRuW7wmdxhn/yWwABcZsA

> 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
> 

• References:
  • RE: basic qs - how is xml more flexible for exchanging data?
    • From: Anil Philip <goodnewsforyou@y...>

• Prev by Date: RE: basic qs - how is xml more flexible for exchanging data?
• Next by Date: RE: Goodbye XML-Deviant
• Previous by thread: RE: basic qs - how is xml more flexible for exchanging data?
• Next by thread: RE: basic qs - how is xml more flexible for exchanging data?
• Index(es):
  • Date
  • Thread