• Subject: Re: using XML to build web pages
  • From: email@xxxxxxxxxxxxxxxxxxx (James W Kilgore)
  • Date: Mon, 29 Nov 1999 00:58:45 -0800
  • Organization: Progressive Data Systems, Inc.


Since I've managed to have dinner and some more thought about your CEO's
request, I would like to state a practical use for XML.

(Don't you just hate it when the CEO reads that airline zine in the
pouch and comes back asking questions? <g>)

Now this example is from a client end (me) looking for a web page that
provides information.  If that information provider should use XML in
their presentation, AND (that's a big and) I should happen to write a
browser plugin to parse a page, I can programmatically input data into
my application.

Let's say that I have a name and address data entry screen. Client,
vendor, employee, whatever.

Sooner or later there will be a place for city, state and zip.  Now,
let's say I'm not sure about the zip but want to do a lookup.

Currently, the solution would be to either build or acquire a city/zip
table that you can lookup locally.  It can be indexed either way, even
have a phonetic lookup on the city.  All the bells and whistles.

It could even find the zip+4 suffix based upon street address and
standardize the spelling along the way.

Then came the web.

So the user has typed in the city.  They've typed in the state.  When it
comes to zip they press (our shop standard F11) to "display choices". 
Instead of calling a local program (that you have to maintain, along
with the table) it does a HTTP request to an internet accessible lookup
service that uses XML to provide you the zip code(s) for that

Your browser plugin parses the HTML source sent by the provider
(displayed or not) and looks for <ZIP>12345</ZIP> for the solution.

In essence, you have "out sourced" your choice values.

The browser plugin could retain that information for local lookup.  But
if that information should change, as zip codes, telephone area codes,
payroll tax tables, etc. -do- change, one must create a plan for
"currency" of information.  Sort of an overnight process to "cache" the
world as we knew it as of 2 am local time.

BTW, Netscape has made their browser source code public so that it can
be customized for specific use.

(later, tic toc ... )

OK, my wife and I grabbed a few chuckles watching Men in Black on
commercial TV, and now for the really big question.  From the server
(CEO request) side of the equation:

If XML exits to allow you to tag data to a recipient, who is the
recipient, what do they what to know?  And more importantly, do they
have the capability to receive what your XML pages give?

So you've gone though all the work to take your HTML pages, and after
checking all of the standards, add
<QuantityOnHand>123456</QuantityOnHand> within your existing <td> ...
</td> tags.

So what was:




You're pitching, but who's catching? IMHO, that's the question that the
CEO needs to consider.

Well, I'm still picking and flossing crow from this past weeks meal <g>,
so here's another toss into the forthcoming consultant list:

In can be cost justifiable to just flat out "give" either a customer or
vendor the XML framework to exchange information.  As a consultant,
after looking over the numbers, it -may- (that's a highly quantifiable
-may-) be my recommendation that my client's cost of operation can be
reduced by elevating the technology of their trading partners.  And that
technology is given at no cost to the trading partner.  Good PR.

Way back when, I was told that the best way to keep a customer was to
make it very easy for them to do business with you. If, in the act of
reducing your costs, you can reduce theirs, you both gain.

Maybe that's the future your CEO has in mind.

Happy Holidays,
James W. Kilgore

Joe Teff wrote:
> I am currently serving html from an AS/400 using
>    o  static html located on the IFS
>    o  Net.Data macros
>    o  CGI written with RPG IV
> I was asked recently if I could use XML to generate the web
> pages instead of HTML. 
> The only reason given as to using XML is the CEO read
> in a magazine that XML is the future. I just want to make sure
> that I'm not missing something here. I just cannot see how
> this makes sense when you simply want to give customers
> inquiry into the status of their orders and projects.
> I'd also like to hear anyone's opinion on using XML in this
> scenario and why it would be good or bad.
> Thanks,  Joe Teff
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].