Page 1 of 3
xml and xsl
Posted: Wed Jan 17, 2007 3:56 am
by raghavan20
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?
Re: xml and xsl
Posted: Wed Jan 17, 2007 6:17 am
by timvw
raghavan20 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 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-scraping

)
raghavan20 wrote:
The added advantage is the syntax is not so complex so web developers can be asked to use it.
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:
But do you think it would really become popular and would replace certain parts of work done by server side languages?
I think the XML hype is dying.. A big disadvantage of XSL is that it consumes a lot of memory...
Re: xml and xsl
Posted: Wed Jan 17, 2007 6:44 am
by raghavan20
timvw wrote:raghavan20 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 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-scraping

)
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:
raghavan20 wrote:
The added advantage is the syntax is not so complex so web developers can be asked to use it.
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).
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:
raghavan20 wrote:
But do you think it would really become popular and would replace certain parts of work done by server side languages?
I think the XML hype is dying.. A big disadvantage of XSL is that it consumes a lot of memory...
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.
Do you see any potential places where use of XML and XSL could be beneficial?
Posted: Wed Jan 17, 2007 7:46 am
by Ollie Saunders
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.
Err what? No way should it be taking that long.
Do you see any potential places where use of XML and XSL could be beneficial?
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.
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.
Posted: Wed Jan 17, 2007 8:13 am
by Jenk
XSLT is client side, thus some are reluctant to use it.
Posted: Wed Jan 17, 2007 8:27 am
by raghavan20
Jenk wrote:XSLT is client side, thus some are reluctant to use it.
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 .
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);
?>
Posted: Wed Jan 17, 2007 8:41 am
by Ollie Saunders
Jenk wrote:XSLT is client side, thus some are reluctant to use it.
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.
Posted: Wed Jan 17, 2007 8:43 am
by raghavan20
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.
I am mainly interested in finding the places where xsl can be used as i heard from sitepoint CMS can be a good place.
EDIT:
ole wrote:Client side is perfectly reliable on firefox
I get the following error message, '
Error loading stylesheet: Parsing an XSLT stylesheet failed.'. how could i debug now?
Posted: Wed Jan 17, 2007 8:48 am
by Ollie Saunders
Well you can use it as a very powerful presentation layer...like smarty only much better. So you can convert any kind of XML data structure into HTML.
Posted: Wed Jan 17, 2007 8:17 pm
by Ambush Commander
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).
I get the following error message, 'Error loading stylesheet: Parsing an XSLT stylesheet failed.'. how could i debug now?
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.
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
Posted: Wed Jan 17, 2007 8:37 pm
by Ollie Saunders
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
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.
must figure out how to automatically serialize objects to XML
Post about it when you figure it out

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.
Absolutely.
Personally, I don't think anyone in their right mind will deploy XSL client-side.
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.
Posted: Thu Jan 18, 2007 3:21 am
by Jenk
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.
Posted: Thu Jan 18, 2007 5:18 am
by Kieran Huggins
Let me preface this by saying that I also adore XSLT. I'm using it, and I couldn't be happier.
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.
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.
ole wrote:Personally, I don't think anyone in their right mind will deploy XSL client-side.
It is a nice fallback when you don't have access to a server with XSL, not much else.
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.
must figure out how to automatically serialize objects to XML
Use DOM objects! (or at least extend them)
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.
Posted: Thu Jan 18, 2007 7:14 am
by timvw
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.
Actually, you still have to maintain all the transformations..
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...
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.
I don't see how XSL would help here...
Posted: Thu Jan 18, 2007 7:33 am
by Kieran Huggins
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.