OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XML=WAP? And DOA?

[ Lists Home | Date Index | Thread Index ]

Jens:

First let me thank you for starting this thread.  Since I have very 
little poetic talents, I was feeling hopelessly inadequate watching the 
display of talent on the "Thread of the Week", the Limerick thread. 
 Even though your post is bit of a flame bait, I feel I at least have 
something to say on this.

Several points you make are correct:

1. XML is definitely not new.  
It can be argued that CSV or other Flat files are XML with invisible 
tags that are already agreed upon by the receiver and the sender.

2. There is nothing that has not been doable for eons with RPC and ASCII
Yes but that was a world without the web and without inter-enterprise 
computing.  Here I would like to paraphrase something Jon Bosak once 
told me.  Think about using RPC as the primary means of transactions 
between 2 business partners.  Now imagine that due to some problem in 
the code, the transactions are now in dispute and the aggrieved parties 
take the case to court for remedy.  How reasonable is it to expect the 
legal system to dig through the court, find the problem and presribe a 
remedy to this?  On the other hand if this was done in the loosely 
coupled sense using XML messages over any transport and the request and 
responses are logged, it is certainly more reasonable to expect the 
court system to have an easier time figuring out the issues and 
prescribe a remedy.  So when it gets to inter-enterprise and between 
smoke stacks or silos within an enterprise, XML may be a better approach 
as opposed to RPC.

I believe:

1. When you are dealing with disparate applications, data sources over 
which you have no control and you have to serve applications and devices 
over which you have no control, XML will certainly ease a lot of your 
burden.  As sure as the sun coming up every day, these sources, 
applications and devices will change and will change often.  The cost to 
you if  you use XML as the plumbing is going to be lot less.

2. When you are dealing with a situation where you are the "master of 
your own destiny" (borrowed this from Mike Champion) and do not foresee 
this changing soon, stick to time tested methods of SQL, RPC and ASCII. 
 You will do just fine.

Now think of a situation where all applications, databases and 
repositories miraculously allow read and write in XML (I can not think 
of why that would be even preferable), all of a sudden the "switching 
cost" that keeps you locked into a particular vendor or application for 
good disappears.  The IP of the spreadsheet, data or the document you 
create is yours.  Then tell me why you have to pay vendors money to be 
able to manipulate it as you wish.

Use XML as little or as much as you want.  Your requirements, 
environment and infrastructure and above all ROI should dictate how deep 
you want to go into this.  I for one believe that I should dip my toes 
in the water a little, test it and check the benefits and then if things 
check out, dip my foot and so on.

Finally to give you some practical perspective, we at B-Bop, in some 
cases, have helped solve customer problem with nothing more than a 
parser, a transformation tool and a few XML files.  While at others, we 
have used XPath, our homegrown XML Query Language and the full power of 
our XML Data Management System to solve a different problem.

So while the peaks and valleys of any new technology can be 
disconcerting and disappointing at times, enjoy the ride but always make 
sure you are getting your money's worth.  If I were a betting man, I 
would bet that this ride is far from being over.  It is only getting 
started, doubts and concerns notwithstanding.

Soumitra




  • References:



 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS