xml and xsl
Moderator: General Moderators
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
xml and xsl
i was looking at a few articles in sitepoint and reading a tutorial in w3schools regarding xsl
http://www.w3schools.com/xsl/default.asp
http://www.sitepoint.com/article/get-xsl-dirty-work
http://www.sitepoint.com/article/transform-php-xslt
it sounds impressive as some of the work of the server - side languages can be replaced by xsl i.e. retrieving and formatting data. The added advantage is the syntax is not so complex so web developers can be asked to use it. But do you think it would really become popular and would replace certain parts of work done by server side languages?
http://www.w3schools.com/xsl/default.asp
http://www.sitepoint.com/article/get-xsl-dirty-work
http://www.sitepoint.com/article/transform-php-xslt
it sounds impressive as some of the work of the server - side languages can be replaced by xsl i.e. retrieving and formatting data. The added advantage is the syntax is not so complex so web developers can be asked to use it. But do you think it would really become popular and would replace certain parts of work done by server side languages?
Re: xml and xsl
I can imagine how xsl can be used to transform data... But i don't see how a XSLT would fetch data from a mysql database.. (If one would decide to use xml/xsl, he can take advantage of the fact that xhtml is xml.. another form of screen-scrapingraghavan20 wrote: it sounds impressive as some of the work of the server - side languages can be replaced by xsl i.e. retrieving and formatting data.
I wouldn't consider this as a selling point. Basic PHP isn't complex either. Once logic is involved, it will become hard for designers... I have seen nice results of designers using Altova XML studio for writing an XSL-FO (.net classes serialized to xml -> pdf).raghavan20 wrote: The added advantage is the syntax is not so complex so web developers can be asked to use it.
I think the XML hype is dying.. A big disadvantage of XSL is that it consumes a lot of memory...raghavan20 wrote: But do you think it would really become popular and would replace certain parts of work done by server side languages?
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
Re: xml and xsl
I am telling about the XPATH capability to read XML documents and retrieve any element in the xml file. I do not what XQuery does, may be it can perform operations on XML database.timvw wrote:I can imagine how xsl can be used to transform data... But i don't see how a XSLT would fetch data from a mysql database.. (If one would decide to use xml/xsl, he can take advantage of the fact that xhtml is xml.. another form of screen-scrapingraghavan20 wrote: it sounds impressive as some of the work of the server - side languages can be replaced by xsl i.e. retrieving and formatting data.)
That is a good question but I still do not understand people still prefer using smarty's own templating language which is even more complex than XSLT. I guess still using non-server-side languages for formatting gives more security.timvw wrote:I wouldn't consider this as a selling point. Basic PHP isn't complex either. Once logic is involved, it will become hard for designers... I have seen nice results of designers using Altova XML studio for writing an XSL-FO (.net classes serialized to xml -> pdf).raghavan20 wrote: The added advantage is the syntax is not so complex so web developers can be asked to use it.
I think that is true because when i associate a XSL with a XML document, it literally takes 5 - 7 seconds to output the xml even when both these files are in local system.timvw wrote:I think the XML hype is dying.. A big disadvantage of XSL is that it consumes a lot of memory...raghavan20 wrote: But do you think it would really become popular and would replace certain parts of work done by server side languages?
Do you see any potential places where use of XML and XSL could be beneficial?
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Err what? No way should it be taking that long.I think that is true because when i associate a XSL with a XML document, it literally takes 5 - 7 seconds to output the xml even when both these files are in local system.
All over the place. I dont' think XML hype is going to die. XML is still in its infancy really, we've yet to see any proper XML optimising tools and hardware is constantly advancing.Do you see any potential places where use of XML and XSL could be beneficial?
At the moment there is a balace between databases and XML. Use XML where data structures are subject to change and/or load is relatively low. Use a databases when this is not the case.
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
what do you actually mean by client-side, i am talking of using xsl like in this example from php.net, http://uk2.php.net/manual/en/function.x ... to-xml.php .Jenk wrote:XSLT is client side, thus some are reluctant to use it.
Code: Select all
<?php
// Load the XML source
$xml = new DOMDocument;
$xml->load('collection.xml');
$xsl = new DOMDocument;
$xsl->load('collection.xsl');
// Configure the transformer
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl); // attach the xsl rules
echo $proc->transformToXML($xml);
?>- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
It is both client and server side. But you should use server side when you can. Client side is perfectly reliable on firefox but its implementation in IE (although just as good) depends on certain things in order to work correctly that, on some corporate machines, can be missing.Jenk wrote:XSLT is client side, thus some are reluctant to use it.
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
I am mainly interested in finding the places where xsl can be used as i heard from sitepoint CMS can be a good place.ole wrote: At the moment there is a balace between databases and XML. Use XML where data structures are subject to change and/or load is relatively low. Use a databases when this is not the case.
EDIT:
I get the following error message, 'Error loading stylesheet: Parsing an XSLT stylesheet failed.'. how could i debug now?ole wrote:Client side is perfectly reliable on firefox
Last edited by raghavan20 on Wed Jan 17, 2007 8:49 am, edited 1 time in total.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Before I read the posts, let me say: I :3 XSLT. Think it's the most elegant thing ever and would use it more if it didn't take so darn long to write them (mostly because of inexperience) and making a DOM to pass the data to wasn't so tedious (must figure out how to automatically serialize objects to XML).
Personally, I don't think anyone in their right mind will deploy XSL client-side. Doesn't make much sense to me, and once people realize XSLT is just as much a programming language as any, security thingies will start popping up.
That being said, XSL is extremely powerful, in that it forces you to figure what data you are trying to show in the web-page, construct a DOM to hand-off to the XSLT processor, then convert it to completely valid XHTML, no ifs, ands or buts. You get the added benefit of instant-XML which you can published for data-scraping and that newfangled mashup business.
For XSLT, the best business is to learn by example. Here's an XSL transformation file I wrote: http://hp.jpsband.org/svnroot/htmlpurif ... /plain.xsl
There's an error in your XML syntax. Run it through an XML validator (or for that matter, just fire up the xsl file in Firefox) and it should become obvious.I get the following error message, 'Error loading stylesheet: Parsing an XSLT stylesheet failed.'. how could i debug now?
Personally, I don't think anyone in their right mind will deploy XSL client-side. Doesn't make much sense to me, and once people realize XSLT is just as much a programming language as any, security thingies will start popping up.
That being said, XSL is extremely powerful, in that it forces you to figure what data you are trying to show in the web-page, construct a DOM to hand-off to the XSLT processor, then convert it to completely valid XHTML, no ifs, ands or buts. You get the added benefit of instant-XML which you can published for data-scraping and that newfangled mashup business.
For XSLT, the best business is to learn by example. Here's an XSL transformation file I wrote: http://hp.jpsband.org/svnroot/htmlpurif ... /plain.xsl
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
I completely agree with you on elegance. Until I looked into XSLT I wasn't too inclinded to use XML, for me XSLT made the difference, and some. As for taking a long time to write, I've only really used it once, everything involved some probing but I can see that with a firm grasp of the fundamentals it good be really fast, faster than anything else I can think of and about 5x faster than SQL.XSLT. Think it's the most elegant thing ever and would use it more if it didn't take so darn long to write them
Post about it when you figure it outmust figure out how to automatically serialize objects to XML
Absolutely.That being said, XSL is extremely powerful, in that it forces you to figure what data you are trying to show in the web-page, construct a DOM to hand-off to the XSLT processor, then convert it to completely valid XHTML, no ifs, ands or buts. You get the added benefit of instant-XML which you can published for data-scraping and that newfangled mashup business.
It is a nice fallback when you don't have access to a server with XSL, not much else. The idea of it is nice though, less load on the server, less to content to serve. Uncharacteristically both FireFox and IE6 have a solid standards compliant implementation of it....shame they couldn't do that with JavaScript.Personally, I don't think anyone in their right mind will deploy XSL client-side.
Client-side XSLT is actually very useful.
We have feeds (similar to RSS feeds, if you like) that are used by systems for raw data. XML sheets don't make pretty pages on their own, so we have created a few XSLT sheets to beautify them. We don't need a webserver for it, only a server directory to centrally store the files.
We have feeds (similar to RSS feeds, if you like) that are used by systems for raw data. XML sheets don't make pretty pages on their own, so we have created a few XSLT sheets to beautify them. We don't need a webserver for it, only a server directory to centrally store the files.
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Let me preface this by saying that I also adore XSLT. I'm using it, and I couldn't be happier.
Every time someone has wrestled with beating their CSS to death to get around markup order, XSLT could have been there. Every time you had to write an entirely new script to produce an RSS feed, XSLT could have been there. There are many more examples... but I digress.
This is an essential point - but should be supplemented by the fact that you only need to write the logic to build this DOM once, then you can transform it to many formats (rss, xhtml, pdf...). That's amazing.That being said, XSL is extremely powerful, in that it forces you to figure what data you are trying to show in the web-page, construct a DOM to hand-off to the XSLT processor, then convert it to completely valid XHTML, no ifs, ands or buts. You get the added benefit of instant-XML which you can published for data-scraping and that newfangled mashup business.
I disagree... sort of. While this is true in some cases for public browsers, you can save a lot of processing overhead when you control the client platform (enterprise) and when data security isn't a big deal. You can check the browser's support for XSLT easily enough, and if needs be save it as a session variable or cookie. This way you can use the server transformation as a fall-back instead.ole wrote:It is a nice fallback when you don't have access to a server with XSL, not much else.Personally, I don't think anyone in their right mind will deploy XSL client-side.
Use DOM objects! (or at least extend them)must figure out how to automatically serialize objects to XML
Every time someone has wrestled with beating their CSS to death to get around markup order, XSLT could have been there. Every time you had to write an entirely new script to produce an RSS feed, XSLT could have been there. There are many more examples... but I digress.
Actually, you still have to maintain all the transformations..Kieran Huggins wrote: This is an essential point - but should be supplemented by the fact that you only need to write the logic to build this DOM once, then you can transform it to many formats (rss, xhtml, pdf...). That's amazing.
Eg: You have some php code that generates the outputs.. In a reasonably designed application this would lead to a base architecture with 5 (php/smarty/...) templates to generate the specific output...
The difference now is that before you can start the transformation, you have to convert the php (or whatever) first to xml.. and then do the transformation.. (The advantage is that your transformation process is loosely coupled with the back-end.. Since all it needs is xml.. And it doesn't care whether php, jws, asp.net generated it...
I don't see how XSL would help here...Kieran Huggins wrote: Every time someone has wrestled with beating their CSS to death to get around markup order, XSLT could have been there. Every time you had to write an entirely new script to produce an RSS feed, XSLT could have been there. There are many more examples... but I digress.
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
markup order: it's always been a pain to implement certain layouts (like 3 column + footer) using CSS when the markup is out of order. XSLT could just transform the order of the markup to something more usable.
rss feeds: if you already have your logic displaying a list or articles or posts or some such nonsense, it's easily transformed into RSS syntax for a feed reader. Or Atom. Or whatever.
rss feeds: if you already have your logic displaying a list or articles or posts or some such nonsense, it's easily transformed into RSS syntax for a feed reader. Or Atom. Or whatever.