Re: using XML to build web pages

I have considered all of that, plus the capability to define multiple
stylesheets
so the customer can choose the style they want to view it in. All nice
things.
What I fail to see is a way to make it happen. I can see how to do it if I
create the XML and store it along with the DFD and XSL. This means that
I can use JavaScript to merge the XML, XSL and DFD on the browser. What
I haven't figured out how to do is create the XML dynamically with CGI
programs
(or Net.Data) and still use JavaScript to merge it with the appropriate DFD
and XSL at the browser. Even if I could do that at the server, they would
loose
any benefit of receiving XML at the browser to plug into their application
of
choice. I am hoping that the next versions IE and Netscape have the XSL
processor built in. I doubt that will happen (or that they are compatible)
since
there is no XSL standard at the moment.

Joe Teff

----- Original Message -----
From: James W Kilgore <email@james-w-kilgore.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, November 29, 1999 2:58 AM
Subject: Re: using XML to build web pages


> 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</ItemDesc
ription></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
+---