Re: almost four years ago....

[hector santos <xml-dev@winserver.com>]

On Jun 15, 2001 12:17am, HOST@XMLEVERYWHERE.COM wrote to ALL:

 > Date: Thu, 14 Jun 2001 21:17:46 -0700
 > From: XML Everywhere <host@xmleverywhere.com>
 > Subject: Re: almost four years ago....
 > To: xml-dev@lists.xml.org

 > XML has to be the most flexible
 > technology I have ever used, and
 > unfortunetely, any flexible tool can become a noose.
 > Thus there will always be complaints about
 > how XML has become unwieldy,
 > and likewise there will always be those who
 > use the technology simply because it
 > solves a real problem.

Interesting comments.  In my opinion, as the saying goes;
"the more things change, the more it remains the same."

In my view, the only good XML has done is to highlight
the idea of a standard nomenclature for world-wide
(platform-independent) communications.  This is good,
at least for us, we think it will help increase our product
marketability by exposing our server connectivity using
XML/SOAP to the outside world.

To achieve this, complexity and a massive learning curve
is required. No doubt, in my view, increase process overhead
is now realized to make it all work.

But its the same old process.  As with anything new, change
is inevitable and typically when redundancy (like overhead,
slowness) sets in, you start to see the same redundancy
reductions ideas to emerge.

Soon someone will develop a XML p-code compiler or design
XRISC (XML Reduced Instruction Set) simply because someone
will get the incredible bright idea that:

         <ORDER>
            <PRODUCTID>...</PRODUCTID>
            <QUANTITY>...</QUANTITY>
            <CUSTOMERINFO>...</CUSTOMERINFO>
         </ORDER>

augmented with all the definition overhead, etc., can be transformed
and delivered in some reduced format! <g>

I had a debate with one of my engineers.  He wanted to change our
fixed structure configuration file that our server reads to an
XML format. Good idea, flexible, allows easy expandability for
the future.  But I don't agree that it will improve server
performance or will it reduce our Q&A.  In fact, it will be
worst. For example:

     ReadConfiguration(TConfigurationData &cf);

will now have to be expanded to read each supported field
represented in the configuration, individually.

Internally, I don't think it is a good idea.  However, to
expose our external interfaces, this is probably ok. Not
because it better than before, but it if allows us to
"advertise" to potential customers and partners "You
can access our system using XML/SOAP", then I think its
good.

Anyway, that's my opinion. I'm certainly no XML expert. :-)

Hector Santos, President 
Santronics Software, Inc. 
http://www.santronics.com