|
Joe, 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 city/state. 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: <tr><td>ABC</td><td>whatever</td><td>123456</td></tr> becomes: <tr><td><ItemCode>ABC</ItemCode></td><td><ItemDescription>whatever</ItemDescription></td><td><QuantityOnHand>123456</QuantityOnHand></td></tr> 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 > <<snip>> > > I was asked recently if I could use XML to generate the web > pages instead of HTML. <<snip>> > > 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.