Comments on: Publishing XML to the web with XSLT: a replacement for the presentation layer http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/ Random articles about programming, computing and the internet. Sun, 13 May 2012 23:08:30 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Mitch Stokely http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-80740 Mitch Stokely Sat, 19 Nov 2011 06:24:25 +0000 http://stevenbenner.com/?p=184#comment-80740 This is a very good article. We need more developers explaining how and when t use XSLT driven web sites, because I think alot of young web kiddos have bought into the notion of the ECMAScript solutions......creating these gigantic libraries of (often) compiled or scripted Javascript that they use to not only simulate some level of interactivity but then abolish the markup model of the web and use scripting API's to move data back and forth over the wire between the page and the server. This effectively ruins the whole request-response web model as well! What a HUGE mess these kids are making of the web now! I say we need to drive home the importance like we did 10 years ago, of the XML and XSLT model, whereby now, we have a generation of browsers that are fully capable of supporting XSLT on the client. Which proper caching and content design, we can remove most of the need for these JQuery and scripted libraries and have kids start using XSLT. The promise is not only faster deliver, more reliable, repurposable content, but also smaller data packets between client and server! No, as content moves between devices in XML, we can plant custom XSLT and CSS text files on them and as users interact with the pages, post back XML and rely on cached XSLT and CSS as needed. One can begin to remove scripts and rely more on XML, as it should be. This is not to say API's script libraries and "web app" systems cant be delivered to clients and are not needed. But it makes what is becoming a fat chunky API layer a much slimmer layer, as it was in the 1990's and needs to be again today in correct web page architecture. The whole purpose of HTML and HTTP and the model behind the protocols and frameworks, and the new XML and XSLT model is just abstraction of layers.....its to have the whole thing run better and faster with less complexity and easier maintenance and delivery of content over the Internet. With new smart phones and many much smaller and "liter" wireless devices to come, we all need to move to the XML and XSLT model here soon; where delivery of data, not scripts and broken API junk, is all these devices will need to relay. Otherwise the "script kiddies" will end up building one giant web javascript app that replaces the browser entirely and we are back to not only the "desktop app" model from the 1980's again, but we are building another API house of cards that hackers have free reign over. Lets all pound away online about the need for education in basic HTML, XHTML, XSL, XML, and XSLT designs....and less Javascript! This is a very good article. We need more developers explaining how and when t use XSLT driven web sites, because I think alot of young web kiddos have bought into the notion of the ECMAScript solutions……creating these gigantic libraries of (often) compiled or scripted Javascript that they use to not only simulate some level of interactivity but then abolish the markup model of the web and use scripting API’s to move data back and forth over the wire between the page and the server. This effectively ruins the whole request-response web model as well! What a HUGE mess these kids are making of the web now!

I say we need to drive home the importance like we did 10 years ago, of the XML and XSLT model, whereby now, we have a generation of browsers that are fully capable of supporting XSLT on the client. Which proper caching and content design, we can remove most of the need for these JQuery and scripted libraries and have kids start using XSLT. The promise is not only faster deliver, more reliable, repurposable content, but also smaller data packets between client and server! No, as content moves between devices in XML, we can plant custom XSLT and CSS text files on them and as users interact with the pages, post back XML and rely on cached XSLT and CSS as needed. One can begin to remove scripts and rely more on XML, as it should be. This is not to say API’s script libraries and “web app” systems cant be delivered to clients and are not needed. But it makes what is becoming a fat chunky API layer a much slimmer layer, as it was in the 1990′s and needs to be again today in correct web page architecture.

The whole purpose of HTML and HTTP and the model behind the protocols and frameworks, and the new XML and XSLT model is just abstraction of layers…..its to have the whole thing run better and faster with less complexity and easier maintenance and delivery of content over the Internet. With new smart phones and many much smaller and “liter” wireless devices to come, we all need to move to the XML and XSLT model here soon; where delivery of data, not scripts and broken API junk, is all these devices will need to relay. Otherwise the “script kiddies” will end up building one giant web javascript app that replaces the browser entirely and we are back to not only the “desktop app” model from the 1980′s again, but we are building another API house of cards that hackers have free reign over. Lets all pound away online about the need for education in basic HTML, XHTML, XSL, XML, and XSLT designs….and less Javascript!

]]> By: Bernd Burkert http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-80637 Bernd Burkert Tue, 04 Oct 2011 17:09:19 +0000 http://stevenbenner.com/?p=184#comment-80637 Hi Steven, great article, I love your promoting the benefits of XSLT. When we started the development of our model-driven CMS onion.net, we decided to go for XSLT rendering according to the benefits you mentioned above. If any of your readers here like to play with XSLT rendering: I encourage you to donload the free evaluation license (productive use may need a full license) of onion.net at http://onion.net/en/community-edition and use it as a test-bed. I somewhat disagree with your statement on rendering performance. onion.net is getting more and more popular here in Germany and actually many customers praise its extreme speed - not only wrt to project development and training but especially wrt to web-page delivery. Take a look at http://www.alexa.com/siteinfo/gutscheincode.org# which is a good example of a onion.net driven site with some traffic and a lot of dynamically placed contents. Actually I did a study comparing Alexa's average load times of the product sites of the ~40 CMS systems featured by the WCM report of the Real Story Group http://www.realstorygroup.com/Reports/CMS/#lb-vendors-list It covers all the big brands, and most of them are not using XSLT rendering technology. Actually there was only one CMS featuring a similar speed like onion.net. Therefore, I would not sign that the delivery speed of XSLT poses any handicap in real-life CMS products. Keep that XSLT flag flying! Regards from Germany, Bernd Hi Steven,

great article, I love your promoting the benefits of XSLT.

When we started the development of our model-driven CMS onion.net, we decided to go for XSLT rendering according to the benefits you mentioned above. If any of your readers here like to play with XSLT rendering: I encourage you to donload the free evaluation license (productive use may need a full license) of onion.net at http://onion.net/en/community-edition and use it as a test-bed.

I somewhat disagree with your statement on rendering performance. onion.net is getting more and more popular here in Germany and actually many customers praise its extreme speed – not only wrt to project development and training but especially wrt to web-page delivery. Take a look at http://www.alexa.com/siteinfo/gutscheincode.org# which is a good example of a onion.net driven site with some traffic and a lot of dynamically placed contents.

Actually I did a study comparing Alexa’s average load times of the product sites of the ~40 CMS systems featured by the WCM report of the Real Story Group http://www.realstorygroup.com/Reports/CMS/#lb-vendors-list It covers all the big brands, and most of them are not using XSLT rendering technology. Actually there was only one CMS featuring a similar speed like onion.net. Therefore, I would not sign that the delivery speed of XSLT poses any handicap in real-life CMS products.

Keep that XSLT flag flying!

Regards from Germany,
Bernd

]]> By: Steven Benner http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-1291 Steven Benner Wed, 19 May 2010 03:02:28 +0000 http://stevenbenner.com/?p=184#comment-1291 Oh I see, yeah I guess I didn't quite understand how you were abstracting the content. That's an interesting approach. Thanks for the information! Oh I see, yeah I guess I didn’t quite understand how you were abstracting the content. That’s an interesting approach. Thanks for the information!

]]> By: Alejandro http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-1258 Alejandro Mon, 17 May 2010 15:07:04 +0000 http://stevenbenner.com/?p=184#comment-1258 I have been misunderstood. In your example the XSLT stylesheet has embedded XHTML semantic. What I propose is to separate transformation (XSLT) from layout page (XHTML). So, do not lose any level of abstraction. In fact, we are adding a level: the connection by using XSLT. XML (data, preferably in a standard vocabulary and not one designed ad-hot) - XHTML (layout for browsers) - XSLT (bindding) - and of course, CSS (design) - and EmacScript (behavior, if necessary) In this way, the whole design of the page for browsers can be done without taking into account the type of linkage with the data, taking full advantage of WYSIWYG editing with any software (not tying to only those that allow the addition of XSLT ), and allowing the separation of concerns in the development team. Regarding IE6, for any XML document to be provided, the browser will remain in standard mode. In fact, the problem is with IE7. If the document resulting from the transformation does not have a DOCTYPE declaration, IE7 interprets the CSS stylesheet like IE6 (losing the ability to use the hover pseudoclass on any element, for example) Check out my site and see how all these minor problems are solved. I have been misunderstood. In your example the XSLT stylesheet has embedded XHTML semantic. What I propose is to separate transformation (XSLT) from layout page (XHTML).
So, do not lose any level of abstraction. In fact, we are adding a level: the connection by using XSLT.
XML (data, preferably in a standard vocabulary and not one designed ad-hot) – XHTML (layout for browsers) – XSLT (bindding) – and of course, CSS (design) – and EmacScript (behavior, if necessary)
In this way, the whole design of the page for browsers can be done without taking into account the type of linkage with the data, taking full advantage of WYSIWYG editing with any software (not tying to only those that allow the addition of XSLT ), and allowing the separation of concerns in the development team.
Regarding IE6, for any XML document to be provided, the browser will remain in standard mode. In fact, the problem is with IE7. If the document resulting from the transformation does not have a DOCTYPE declaration, IE7 interprets the CSS stylesheet like IE6 (losing the ability to use the hover pseudoclass on any element, for example)
Check out my site and see how all these minor problems are solved.

]]> By: Steven Benner http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-1244 Steven Benner Sun, 16 May 2010 20:05:11 +0000 http://stevenbenner.com/?p=184#comment-1244 If you're building an XHTML document anyway I don't see the benefit of using XSLT to modify that document. You're loosing the abstractions between data and layout and risking backwards compatibility issues with IE6. Only XHTML 1.1 specifically allows (and requires) XML declarations, but IE6 does not support XHTML 1.1 because of the XML declaration. The first line of any HTML document must be a DOCTYPE statement or IE6 reverts to quirks mode. All modern browsers support XHTML 1.1, but IE6 is still too common to ignore especially for a business. (Granted, this site doesn't work with IE6) The only place XSLT can be reliably used if you need to support old browsers is on an XML document. If you’re building an XHTML document anyway I don’t see the benefit of using XSLT to modify that document. You’re loosing the abstractions between data and layout and risking backwards compatibility issues with IE6. Only XHTML 1.1 specifically allows (and requires) XML declarations, but IE6 does not support XHTML 1.1 because of the XML declaration. The first line of any HTML document must be a DOCTYPE statement or IE6 reverts to quirks mode.

All modern browsers support XHTML 1.1, but IE6 is still too common to ignore especially for a business. (Granted, this site doesn’t work with IE6)

The only place XSLT can be reliably used if you need to support old browsers is on an XML document.

]]> By: Alejandro http://stevenbenner.com/2010/02/publishing-xml-to-the-web-with-xslt-a-replacement-for-the-presentation-layer/#comment-1204 Alejandro Fri, 14 May 2010 19:48:13 +0000 http://stevenbenner.com/?p=184#comment-1204 Despite the fact that many deny the use of XSLT on the client, is a technology common to the vast majority of modern browsers. It is much more compatible than EmacScript between different browsers. For all tasks involving static modification of a DOM based on an XML document, XSLT is faster and easier than EmacsScript. The difficulty lies in learning the declarative programming approach. On the other hand, I would not recommend the use of the semantics of XHTML within the XSLT style sheet. It is better to provide separate XHTML page and data (in an XML document with standard vocabulary) allowing the XSLT stylesheet to make the connection. In example www.aranedabienesraices.com.ar Despite the fact that many deny the use of XSLT on the client, is a technology common to the vast majority of modern browsers. It is much more compatible than EmacScript between different browsers.
For all tasks involving static modification of a DOM based on an XML document, XSLT is faster and easier than EmacsScript. The difficulty lies in learning the declarative programming approach.
On the other hand, I would not recommend the use of the semantics of XHTML within the XSLT style sheet. It is better to provide separate XHTML page and data (in an XML document with standard vocabulary) allowing the XSLT stylesheet to make the connection.
In example http://www.aranedabienesraices.com.ar

]]>