Discussion
Several years after everyone else I've finally spent some time twigging XML and XSL.
Now I understand the potential of it I was wondering how people use it in the real world when it comes to page generation on sites.
I suspect I could move from an ASP/CSS model to a tiny bit of ASP and use XML/XSL/CSS to generate complete pages from XML pages generated from lightweight ASP.
Should I really be looking at that route or would that not in fact simplify matters?
Now I understand the potential of it I was wondering how people use it in the real world when it comes to page generation on sites.
I suspect I could move from an ASP/CSS model to a tiny bit of ASP and use XML/XSL/CSS to generate complete pages from XML pages generated from lightweight ASP.
Should I really be looking at that route or would that not in fact simplify matters?
Ted,
Like most techologies it has it's uses and like most technologies people tend to use it because it looks good on a CV too!
I've used it fairly extensively in a couple of projects. One being a data transfer (exchanging XML messages from MQ, reformatting them to a different DTD then passing them to another process) the other project being a multi browser UI project where you have different XSL stylesheets for different browser types (ie high graphic PC, low graphic PC, PDA, WAP etc).
Used in the above contexts it works very well since you just have a single XML/XSL digester that outputs the data you want, in the UI project this was a J2EE servlet (also done the same with ASP).
I would imagine you are looking at it for it's "single-data multiple format" usage, in which case it's a doddle in ASP. The TVRCC Northants site I designed uses XML/XSL for common data feeds (news etc) where you want to display the same data in slightly different ways.
Drop me a mail if you want some examples, tips.
Good luck
Steve
>> Edited by fatsteve on Monday 21st June 18:58
Like most techologies it has it's uses and like most technologies people tend to use it because it looks good on a CV too!
I've used it fairly extensively in a couple of projects. One being a data transfer (exchanging XML messages from MQ, reformatting them to a different DTD then passing them to another process) the other project being a multi browser UI project where you have different XSL stylesheets for different browser types (ie high graphic PC, low graphic PC, PDA, WAP etc).
Used in the above contexts it works very well since you just have a single XML/XSL digester that outputs the data you want, in the UI project this was a J2EE servlet (also done the same with ASP).
I would imagine you are looking at it for it's "single-data multiple format" usage, in which case it's a doddle in ASP. The TVRCC Northants site I designed uses XML/XSL for common data feeds (news etc) where you want to display the same data in slightly different ways.
Drop me a mail if you want some examples, tips.
Good luck
Steve
>> Edited by fatsteve on Monday 21st June 18:58
Hi Steve,
Thanks for your response.
What I'm debating is how to construct my pages in future. Traditionally it's all done in ASP building the whole lot in HTML querying the database along the way to determine the content and hierarchy/menus etc.
Then I reconstructed some pages in XHTML and they're now a lot simpler and cleaner. They are generated by a fairly lightweight ASP page based on a class. Different pages implement some of the functionality differently and with different stylesheets to achieve different content.
Having played with XML now, I see the opportunity to specify all the data/content in XML and use XSL/CSS to render it.
Is that really how people implement pages now? It completely seperates content and style which is good, but I wonder if it might get a bit complex when drawing various different bits of info into the same page.
For example, in my track day section, in theory I could have ASP generated (or static) XML input files for menus, the news items and the track day calendar.
Is this best assembled in ASP with some logic or do I attempt to build a CSS/XSL to pull those together and render them?
Any advice on what your experiences have been would be extremely welcome.
Thanks,
Ted
Thanks for your response.
What I'm debating is how to construct my pages in future. Traditionally it's all done in ASP building the whole lot in HTML querying the database along the way to determine the content and hierarchy/menus etc.
Then I reconstructed some pages in XHTML and they're now a lot simpler and cleaner. They are generated by a fairly lightweight ASP page based on a class. Different pages implement some of the functionality differently and with different stylesheets to achieve different content.
Having played with XML now, I see the opportunity to specify all the data/content in XML and use XSL/CSS to render it.
Is that really how people implement pages now? It completely seperates content and style which is good, but I wonder if it might get a bit complex when drawing various different bits of info into the same page.
For example, in my track day section, in theory I could have ASP generated (or static) XML input files for menus, the news items and the track day calendar.
Is this best assembled in ASP with some logic or do I attempt to build a CSS/XSL to pull those together and render them?
Any advice on what your experiences have been would be extremely welcome.
Thanks,
Ted
Ted,
Unfortunately there is no right or wrong. If you are simply regurgitating data from a DB then simple ASP will work fine. The problem is that you need to develop a framework (ie how you store and format data) before you will start to yield any time-saving results.
Even with XML, I still tend to store data in a database and use code to extract and format that data into XML (or nowadays use raw XML in the db - Oracle is particulary good at this, so is SQL Server).
Essentially you are heading down a pure content management system. However, in my experience you can never use things out of the box. So you'll end up with nice XML/XSLT pages for the bulk of the site, but still have a number of custom ASP pages.
Have you looked at RSS for the widget feeds, this is a classic example where you'd provide pure XML as the feed and pass it though an XSL stylesheet to make it pretty [url]RSS|www.webreference.com/authoring/languages/xml/rss/intro/[url]
Steve
>> Edited by fatsteve on Monday 21st June 19:55
Unfortunately there is no right or wrong. If you are simply regurgitating data from a DB then simple ASP will work fine. The problem is that you need to develop a framework (ie how you store and format data) before you will start to yield any time-saving results.
Even with XML, I still tend to store data in a database and use code to extract and format that data into XML (or nowadays use raw XML in the db - Oracle is particulary good at this, so is SQL Server).
Essentially you are heading down a pure content management system. However, in my experience you can never use things out of the box. So you'll end up with nice XML/XSLT pages for the bulk of the site, but still have a number of custom ASP pages.
Have you looked at RSS for the widget feeds, this is a classic example where you'd provide pure XML as the feed and pass it though an XSL stylesheet to make it pretty [url]RSS|www.webreference.com/authoring/languages/xml/rss/intro/[url]
Steve
>> Edited by fatsteve on Monday 21st June 19:55
Another potential use of XML which I have been discussing with a number of clients is using it to store the data itself, instead of storing it in the traditional way within a SQL database. The advantage my clients are seeing is that the data can be queried or re-used elsewhere - similar, I suppose, to the way that RSS works.
We've done a number of XML-based projects and during the course of them, my XML guy has been in touch with the "XML Guru", Michael Kay, who told him that there is no right or wrong way, as mentioned above.
We've done a number of XML-based projects and during the course of them, my XML guy has been in touch with the "XML Guru", Michael Kay, who told him that there is no right or wrong way, as mentioned above.
Steve, I've got a framework, content management system and everything is database driven. I'm just curious about how far would be sensible to go with moving to a delivery mechanism using data->XML->XSL->HTML versus data->ASP->HTML.
Like you say, a mixture is probably best. I'm trying to determine at what level to base the new framework for pages.
Like you say, a mixture is probably best. I'm trying to determine at what level to base the new framework for pages.
It depends what you want to achieve. There's no point doing something just for the sake of it... I'm a great believer in not making my life hard for myself! 
As per Zeldman's book I'm now settled firmly in the seperation of structure from presentation camp, but beyond that the lines are harder to draw. When you're dealing with content management systems, it's very hard to separate content from structure. And often more trouble than it's worth. You've seen the amazing advantages well structured XHTML can give in terms of performance and compatability, why not concentrate on bringing your hundreds of ASPs up to date with XHTML and CSS before attempting something hugely ambitious?
For presenting data on a webpage I'm still perfectly happy with the tried and tested route of Database -> ASP and it's being used to great effect in Igentics' new website. If you'd like to see inside our content management system or any sample code then drop me a line.
As per Zeldman's book I'm now settled firmly in the seperation of structure from presentation camp, but beyond that the lines are harder to draw. When you're dealing with content management systems, it's very hard to separate content from structure. And often more trouble than it's worth. You've seen the amazing advantages well structured XHTML can give in terms of performance and compatability, why not concentrate on bringing your hundreds of ASPs up to date with XHTML and CSS before attempting something hugely ambitious?
For presenting data on a webpage I'm still perfectly happy with the tried and tested route of Database -> ASP and it's being used to great effect in Igentics' new website. If you'd like to see inside our content management system or any sample code then drop me a line.
Bonce said:
As per Zeldman's book I'm now settled firmly in the seperation of structure from presentation camp, but beyond that the lines are harder to draw. When you're dealing with content management systems, it's very hard to separate content from structure. And often more trouble than it's worth. You've seen the amazing advantages well structured XHTML can give in terms of performance and compatability, why not concentrate on bringing your hundreds of ASPs up to date with XHTML and CSS before attempting something hugely ambitious?
Based on that book you recommended, I'm now firmly in the CSS/XHTML camp and a pretty simple ASP/class thing going on to deliver it.
I then started dabbling with XML to tranfer between sites/pages and was wondering about going the whole hog.
I'll keep dabbling
I used xslt with xsl-fo to create build sheets for a car plant at Swindon and I think it's great to create repeated fixed layout pages with variable data. However, to create more dynamic HTML page layouts I think I'd still choose HTML in a JSP page with the JSP tags to layout the variable data (presumably this is similar to ASP). I just think it gives more flexibility.
Mark
Mark
All good responses, but no-one's mentioned the fact that you can save a significant amount of bandwidth using an XML / XSLT model.
Generate XML in the middle tier, using ASP or whatever. Then write a simple function which queries the user's browser user agent to work out if it's XSLT capable. If it isn't, do the transformation server side and send them the HTML. If it is, paste a reference to the appropriate XSLT into the top of the XML, then send them the XML. Their browser then pulls down the XSLT separately from the XML.
Why is this cool, you may be asking yourself. Well, if you have repeat users who visit similar pages again and again (like gassing users for example), they only pull the XSLT down once, then IE caches it like any other include (CSS, javascript, etc). Providing you design efficient XML schemas, and a lot of your users access the site via IE 6, then the bandwidth use can be dramatically reduced. In fact, if your pages involve lots of repeating structures, again like the Gassing Station, the XML + XSLT combined download is smaller than the resulting HTML even without the effect of caching.
I use exactly this technique for an app accessed via slow mobile connections, where it's not so much the cost of the bandwidth as the time to refresh each page which is important. Mind you, if it's images which form the bulk of your bandwidth utilisation, this won't help you!
Last point - if you use SQL Server as the database backend, you can use SQLXML to pull richly structured XML documents directly from the database, without having to maintain a load of code in the middle tier to parse recordsets into XML.
Hope this helps,
Pete
p.s. Content syndication - XML is great for allowing other sites to use your content but apply their own look and feel. Perhaps not ideal for your business model though...
Generate XML in the middle tier, using ASP or whatever. Then write a simple function which queries the user's browser user agent to work out if it's XSLT capable. If it isn't, do the transformation server side and send them the HTML. If it is, paste a reference to the appropriate XSLT into the top of the XML, then send them the XML. Their browser then pulls down the XSLT separately from the XML.
Why is this cool, you may be asking yourself. Well, if you have repeat users who visit similar pages again and again (like gassing users for example), they only pull the XSLT down once, then IE caches it like any other include (CSS, javascript, etc). Providing you design efficient XML schemas, and a lot of your users access the site via IE 6, then the bandwidth use can be dramatically reduced. In fact, if your pages involve lots of repeating structures, again like the Gassing Station, the XML + XSLT combined download is smaller than the resulting HTML even without the effect of caching.
I use exactly this technique for an app accessed via slow mobile connections, where it's not so much the cost of the bandwidth as the time to refresh each page which is important. Mind you, if it's images which form the bulk of your bandwidth utilisation, this won't help you!
Last point - if you use SQL Server as the database backend, you can use SQLXML to pull richly structured XML documents directly from the database, without having to maintain a load of code in the middle tier to parse recordsets into XML.
Hope this helps,
Pete
p.s. Content syndication - XML is great for allowing other sites to use your content but apply their own look and feel. Perhaps not ideal for your business model though...
I'm with Bonce on this - keep it simple.
If you have data in a DB and want a web page in HTML do it the simplest way for you. In this case DB -> ASP ->HTML (or XHTML).
We had a chap in who insisted we went DB -> XML -> ASP -> XSLT -> HTML when all he was doing was displaying a list of DB records. Now whilst an elegent solution, it was overkill and a sod to support. So now we just use DB -> ColdFusion -> XHTML - much more straightforward.
However, XML+XSLT (and as mentioned XSL-FO) is a very powerful tool, so we do use it where appropriate. For example we publish scientific papers that at the end contain citations to other published work. We hyperlink these citations where possible. The way we do this is to load the article into an XML DOM, then query the citation database and get the results as an XML DOM - then it is a simple XSLT function to apply the results - hey presto dynamically generated article with updated citations. This is done by accessing the MSXML parser via ColdFusion (you can do it via ASP as well), and is very quick.
We did play around with getting end users to do the XSLT as pete suggests - but we found it created more problems than it solved, so now its all server based.
If you have data in a DB and want a web page in HTML do it the simplest way for you. In this case DB -> ASP ->HTML (or XHTML).
We had a chap in who insisted we went DB -> XML -> ASP -> XSLT -> HTML when all he was doing was displaying a list of DB records. Now whilst an elegent solution, it was overkill and a sod to support. So now we just use DB -> ColdFusion -> XHTML - much more straightforward.
However, XML+XSLT (and as mentioned XSL-FO) is a very powerful tool, so we do use it where appropriate. For example we publish scientific papers that at the end contain citations to other published work. We hyperlink these citations where possible. The way we do this is to load the article into an XML DOM, then query the citation database and get the results as an XML DOM - then it is a simple XSLT function to apply the results - hey presto dynamically generated article with updated citations. This is done by accessing the MSXML parser via ColdFusion (you can do it via ASP as well), and is very quick.
We did play around with getting end users to do the XSLT as pete suggests - but we found it created more problems than it solved, so now its all server based.
Another thing worth considering is how often you want to change things.
Another advantage of going XML/XSLT is that if you want to make a change to the way the markup is generated, there's no need to jump into code, you just change the relevant XSLT. And even graphic designers can cope with that much so there's less work for the real programmers. Of course if you're programmer, graphic designer and tea boy then it may be easier to jump into code. 
Another advantage of going XML/XSLT is that if you want to make a change to the way the markup is generated, there's no need to jump into code, you just change the relevant XSLT. And even graphic designers can cope with that much so there's less work for the real programmers.
Of course if you're programmer, graphic designer and tea boy then it may be easier to jump into code. pete said:
All good responses, but no-one's mentioned the fact that you can save a significant amount of bandwidth using an XML / XSLT model.
Generate XML in the middle tier, using ASP or whatever. Then write a simple function which queries the user's browser user agent to work out if it's XSLT capable. If it isn't, do the transformation server side and send them the HTML. If it is, paste a reference to the appropriate XSLT into the top of the XML, then send them the XML. Their browser then pulls down the XSLT separately from the XML.
Why is this cool, you may be asking yourself. Well, if you have repeat users who visit similar pages again and again (like gassing users for example), they only pull the XSLT down once, then IE caches it like any other include (CSS, javascript, etc). Providing you design efficient XML schemas, and a lot of your users access the site via IE 6, then the bandwidth use can be dramatically reduced. In fact, if your pages involve lots of repeating structures, again like the Gassing Station, the XML + XSLT combined download is smaller than the resulting HTML even without the effect of caching.
I use exactly this technique for an app accessed via slow mobile connections, where it's not so much the cost of the bandwidth as the time to refresh each page which is important. Mind you, if it's images which form the bulk of your bandwidth utilisation, this won't help you!
Last point - if you use SQL Server as the database backend, you can use SQLXML to pull richly structured XML documents directly from the database, without having to maintain a load of code in the middle tier to parse recordsets into XML.
Hope this helps,
Pete
p.s. Content syndication - XML is great for allowing other sites to use your content but apply their own look and feel. Perhaps not ideal for your business model though...
I was just about to reply to this post when I realised who was writing it, so 
(I also know what app you're talking about! 
) Anyway, I just wanted to comment on SQLXML in MS SQL Server. I'm not sure if you're aware but the app in question had some issues with performance due to SQLXML calls taking an inordinate amount of time to retrieve complex data spread across multiple tables. As part of a performance review Tim B replaced all the SQLXML calls in our implementation with Stored Procedures - the improvement in speed was devastating*.
Finally, great point about badnwidth and nice car!
*I can remember the exact figures but I think it was several times as fast.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff