I heard a lot about XML when it first came out, but ignored it, since I couldn't see the application. Now, I'm getting ready to do another database-driven website, and by doing some reading first, I came upon XML again.

A lot of articles talk about XML and XSL as creating reusable components that you can plug into any ASP webpage, rather than writing response.write statements to create a table of data, for example.

Okay, that's interesting, I think. How do I do that? What are the advantages? No no, scratch that, I've read 1,000 pages where people sing the XML praises. Okay, what's the simple example? How do I create my DSN connection and pull some XML junk from the SQL statement and throw that onto my page? (It's a DSN pointing to an MDB, so none of that wacky FOR XML is usable as in SQL Server.) What about a page of several examples. And then, after I can see it, why did they do it that way? Most stuff I've seen generates an XML file first using response.write, so that seems about worthless.

Basically, where's the page that says "Before XML" and "After XML". Anyone know?

If all you want to do is pull some data from Access using ASP to create a web page, I'm not sure how much benefit XML will be to you. I never used XML much previously, but with ASP.NET I'm starting to get into it.

I do have a book, "Professional ASP XML", Wrox Press Ltd, June 2000, ISBN 1-861004-02-8. It seems to cover your questions pretty well. Unfortunately I don't have enough experience with ASP and XML to give you a good answer (and it's been a long time since I looked at this book), but if you can find this book it may help you out.

If you can give us a better idea of what your new website is supposed to do, we might be able to give better suggestions as to whether or not XML will be beneficial to you.

I feel your pain - I asked the same questions when I first started in this. What good is XML to me??

For a small developer who is making a little website - XML may not help much except in things like making a directory structure or a news system/blog for your site. It will save you the trouble of having to connect to a database everytime a person looks at your site. You won't have that overhead, and you won't have to worry about connectivity issues. Like if the DB goes down you are scrwed...not so with XML. XML is all about SHARING the data you have with others and allowing them to pull it into THEIR systems and work with it. but to give you an example, I will show you a site that I did totally with XML/XSLT/HTML. This was my first venture and was more of a "ok - what can XML do for me" proof of concept site...sounds like what you are doing...

http://www.fdle.state.fl.us/capitol_police/capitol_police_home.asp

To change anything on the site all I need to do is to edit one of two XML files. One runs the navigation system and the other contains all the data on each page. These are just simple text files with data and tags. The third file I have is a single XSLT file that actually generates the whole page along with the dynamically changing nav bar on the right.

There's no need to build a backend to tie into the database, no admin interface, very little editing of individual pages. Just open up the data and change as you like.

Here's a snippet of the XML that drives the nav system...





Here is the code snippet for creating the dynamic nav



The XSLT is pretty sloppy I know...so before you gurus tear me a new one...I know I know I know...

So if I want to add a new page, I just add a new NAV tag for a whole new entry or a new SUB tag under the NAV for a subpage of that particular area. The XSLT just reads in the new XML file and voila - a changed nav system. Add the appopriate content to the content XML file and it's added to the site as well.

The only ASP I did in this was to load the XML document (hence the .ASP extension).

The REAL power of XML comes in the fact that it is a common way for disparate systems to exchange information. Sharing data is the key to unlocking what XML can do for you. It does it really easily and it's simple to actually look at and understand. Think web services. Nearly impossible to do without a standard like XML. For example doing payment gateways. If you have say an AS400 or a Sun Sparc talking to some guy's Windows PC at home, XML makes that data transfer easy.

XML is one of those things - like OOP porgamming - it's hard to understand exactly how it is going to help you, but once you are able to wrap your brain around it - you start seeing it's use EVERYWHERE. Trust me - I do.

Thanks for the example. I can see how that can make things easy to load/setup a small dataset for application parameters. I'm still not sure if there are large database applications/advantages. (Like my dispatching system for an auto transport business where the employees access the database online on separate systems and search/page through thousands of records and filter with complex joins.)

Part of my interest is that I've stumbled upon Mozilla's XUL language. Since that dispatch system is a specific application for a specific company which can use a specific browser, then such an easy development platform makes sense. However, it talks about connecting to / importing from an XML datasource, and I'm like, "Eh? XML? That's interesting. How do I do that?"

So, either way, despite the warnings of "It may not be useful for you," I'd still like to learn it. And I'm not limited to ASP, I've just never got around to using ASP.NET. Once again, it was a case of: is this new language worth using? Will it cut down my development time? Will it cut down my maintenance time? Do the advantages outweigh the disadvantages (one being learning it).

So, like my last project, I'm sitting in front of my next one and saying, Do I develop it with the same ASP, ADODB Connection, and Response.Write, or is there something better that I should learn while doing this project? Will I later wish I had used a different technology?

Without describing the next project, I can safely say that most of my projects are very database intensive, with lots of DHTML, swapping elements, using RPCs, etc. They're basically web applications, web software for specific companies, not just web pages with a few dynamic pieces generated by ASP.

So, what about switching to ASP.NET? What about using more XML? And this might be rare, but has anyone designed with XUL? What type of coding lends itself best to changing the structure 6 months down the road, or using pieces of a dynamic table on multiple pages? And what's the learning curve?

I'd say ASP.NET would be a really good fit for what you describe. But, there is a significant learning curve. I can also say though that developing a decent web app in ASP.NET is much easier than ASP. Given the general description of the apps you build, I expect you'll find benefits to using XML somewhere in your app. And, .NET has a lot more built in support for XML than ASP.

One very good use I've found for XML is when using Access Data Projects (ADPs) for a front-end to SQL Server. ADPs do not have the benefit of local storage for lookup tables etc, and there's no reason to constantly query the server ... I've set up routines where the drop-down lists are populated via ADODB recordset saved into XML, and it's worked very well.

Bryant