XML transformations using XSL
Hi, I'm doing some work involving multiple XML feed generation from one data source. Think SMIL, XSPF, RSS, iTunes, PLS, M3U...all use a similar data source: music playlists. Currently each XML feed is generated with a callback function written in PHP. I was thinking the other day, perhaps a better approach would be to provide all the data in one XML file and then convert this file to other XML schemas using XSL. Does such an approach make sense? Anyone done something similar? The reason I thought this might be useful is because then it becomes easy to support multiple XML schema's by simply writing another XSL template and plugging it in to some generalized transformation function. -Farsheed __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
XSL has always been on my list of good ideas I never got to, but that is the way it's supposed to work. On 5/24/06, Farsheed <tfarsheed@yahoo.com> wrote:
Hi,
I'm doing some work involving multiple XML feed generation from one data source. Think SMIL, XSPF, RSS, iTunes, PLS, M3U...all use a similar data source: music playlists.
Currently each XML feed is generated with a callback function written in PHP. I was thinking the other day, perhaps a better approach would be to provide all the data in one XML file and then convert this file to other XML schemas using XSL. Does such an approach make sense? Anyone done something similar? The reason I thought this might be useful is because then it becomes easy to support multiple XML schema's by simply writing another XSL template and plugging it in to some generalized transformation function.
-Farsheed
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 5/24/06 11:42 AM, Farsheed wrote:
Currently each XML feed is generated with a callback function written in PHP. I was thinking the other day, perhaps a better approach would be to provide all the data in one XML file and then convert this file to other XML schemas using XSL. Does such an approach make sense? Anyone done something similar? The reason I thought this might be useful is because then it becomes easy to support multiple XML schema's by simply writing another XSL template and plugging it in to some generalized transformation function.
This may or may not buy you much time - php xslt processing has some caveats - first, the API is completely different php4 vs. php5 ... plus there is processing overhead (beyond what straight php generation of the formats is). Also, it requires format implementation to be done in a 3rd syntax - that not everyone is aware (simple things in XSL are simple - but it's easy to get complicated in a hurry). My experience with XSL is ... it's a nice idea, *but*... is your playlist data already in an XML format? or is it not coming from a database result set? If already in XML, then it might make sense to transform rather than parse & regenerate... otherwise probably not worth it. my $0.02 CAD -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 25 May 2006, at 3:20 AM, James Walker wrote:
My experience with XSL is ... it's a nice idea, *but*... is your playlist data already in an XML format? or is it not coming from a database result set? If already in XML, then it might make sense to transform rather than parse & regenerate... otherwise probably not worth it.
Yup. Using XSLT adds a hell of a lot more 'moving parts' than is strictly necessary, and in general working with a database is far far simpler, and more easily maintainable by a larger group of people. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Yup. Using XSLT adds a hell of a lot more 'moving parts' than is strictly necessary, and in general working with a database is far far simpler, and more easily maintainable by a larger group of people. Yep, and strictly speaking XSL is an overcomplicated beast - too general for its own good. It can be useful is some specific cases, but within drupal it is better to stick to php. It is a XML processing instruction after all, hence the <?php ?>
Thanks for all the feedback. It seems that XSLT is useful in applications where the data is *only* available through XML, but otherwise working with the database is much easier. I'll probably stick with PHP functions, maybe try to find a way to make XML generation a generalized process. One interesting thing I've seen macromedia do is they'll have an 'import xml schema' feature where you load in an example xml file and it reads the structure and then provides that as a structured template. Then you bind data from your own application to different parts of the template and it generates the feed for you. This way it would be easy to define new XML. But again, don't know if this would really be any easier or faster than a custom php function. Another advantage to having this setup is that you could do the reverse: parse incoming feeds with the same template and insert fields into the database by binding the data. --- drupal <vlado@dikini.net> wrote:
Yup. Using XSLT adds a hell of a lot more 'moving parts' than is strictly necessary, and in general working with a database is far far simpler, and more easily maintainable by a larger group of people. Yep, and strictly speaking XSL is an overcomplicated beast - too general for its own good. It can be useful is some specific cases, but within drupal it is better to stick to php. It is a XML processing instruction after all, hence the <?php ?>
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
my $.02, I used XSLT for a project like this a couple years ago. It is designed for this kind of thing and is very cool. However it is likely (as others point out) that there are a lot of features you don't need and furthermore XSLT is (IMO) one of those "wacky" tools that just seems to want to do everything "sideways" - the learning curve is pretty stiff. Dan
Yup. Using XSLT adds a hell of a lot more 'moving parts' than is strictly necessary, and in general working with a database is far far simpler, and more easily maintainable by a larger group of people.
Yep, and strictly speaking XSL is an overcomplicated beast - too general for its own good. It can be useful is some specific cases, but within drupal it is better to stick to php. It is a XML processing instruction after all, hence the <?php ?>
XSLT is a very cool and powerful beast once you learn how to talk to it. The mistake many people make is trying to treat it as a programming language. It isn't. It's a templating/transformation language with functional programming concepts (think ML). If you're converting one XML stream into another XML stream, XSLT is just what you need. I use it for a DocBook->XHTML/DocBook->XSLFO->PDF project, and it's great. If you have to go to the effort of manually building or dissecting the XML on one side or the other, though, then you're probably better off just skipping that step in the first place. Although PHP using <?php ?> doesn't make it inherently an XML PI. If anything, the two clash like crazy if you have short tags enabled. :-) -- Larry Garfield On Thu, May 25, 2006 10:56 am, Dan Robinson said:
my $.02,
I used XSLT for a project like this a couple years ago. It is designed for this kind of thing and is very cool. However it is likely (as others point out) that there are a lot of features you don't need and furthermore XSLT is (IMO) one of those "wacky" tools that just seems to want to do everything "sideways" - the learning curve is pretty stiff.
Dan
Yup. Using XSLT adds a hell of a lot more 'moving parts' than is strictly necessary, and in general working with a database is far far simpler, and more easily maintainable by a larger group of people.
Yep, and strictly speaking XSL is an overcomplicated beast - too general for its own good. It can be useful is some specific cases, but within drupal it is better to stick to php. It is a XML processing instruction after all, hence the <?php ?>
participants (7)
-
Adrian Rossouw -
Dan Robinson -
drupal -
Earl Dunovant -
Farsheed -
James Walker -
Larry Garfield