BrianT wrote:

>HP made the first mention of XML on the the 3000 at this week's Software
>Symposium.

After reading this article, if you're left with the sense of "Big Deal" -
good.  That's the point.  In the article, Alvina Nishimoto said there is a
lot of noise about XML and se's right.  Let's face it.  We're not talking
about rocket science here.  (And if we were, I would want Wirt to write this
reply...)  If you had set up a MIME type on your server to handle the
text/XML, you could claim that you have had XML support for years already.
Serving up ASCII XML files is no different than serving up ASCII HTML files
(At least until it hits the browser...)

Alvina is quoted:

"Once the application server has parsed the XML, it often uses ODBC or JDBC
to connect the database."

Now we get to middleware portion of XML.  Why use ODBC or JDBC when I can
make my efficient TurboImage calls (with TPI and not adding the Allbase
layer) and return one or more elements to an application server?  XML can
eliminate the need for loading ODBC and JDBC drivers on all of your client
machines.  (Not to get off track here but I am not saying that XML will
replace ODBC or JDBC.  It is not faster to take efficient binary
representations of data, transform it into ASCII XML files, transmit it and
then convert it back to its binary representation.  It only makes sense to
do this when the only way to transmit or receive data from an unknown host
is with some lowest common protocol.)  The other benefit of using XML as
middleware is that it can represent more complex structures than a straight
two-dimensional table.  Your XML document can have a header and repeating
detail lines and all of the data will be in a human readable form.  Dates
can appear as dates and not integers.  Special codes can appear as well a
their descriptions.

The article ends with:

"HP is contemplating doing a parser for the e3000, but typically we find
people are working with an application server on NT or Unix, and need to
access IMAGE data. The parser would allow a customer to host their Web
application entirely on e3000 systems. Since we do have ODBC and JDBC on the
3000, it works just fine with the [NT and Unix] services."

There are a few parsers available in Java that should work just fine on the
3000 and one could use a Java-based application server there too.  My
concern is with the legacy systems.  A parser that can be called from Cobol,
Fortran, SPL, Transact and Basic would expose more data to the web.  It
would also make it easier for the update routines for inbound XML documents.
One draw back of ODBC and JDBC is that they don't enforce the business rules
or the security policies of your legacy code.  Trying duplicate those rules
in a thick client or in application server code may introduce new errors.
If the 3000 is going to accept eCommerce data, I believe that a parser for
the traditional languages will be necessary.

In another post, Lars Appel asks about www.xmlsoft.org's parser.

I have not used it, but it appears to be based on Expat written by Jim
Clark.  This parser is the one used in the open source Netscape browser.
This page mentions that this parser is DOM-Like and SAX-like.  Does that
mean it is "like - standard"?  Anyway, there are basically two kinds of
parsers DOM and SAX.  DOM stands for the Document Object Model.  This kind
of parser reads the entire document into memory and makes a tree
representation of the it.  You can walk the tree, add/delete children, etc..
On the other hand, there is the SAX compliant parser.  SAX stands for the
Simple API for XML and it is an event-based parser.  In this kind of parser,
one registers routines with different types of events.  For example, for
every start tag execute this call-back function, etc.  This parser does not
load the entire document into memory and it is used for large files.  For
more information on SAX and its newest version, see www.megginson.com