CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Peter's Gekko

public Blog MyNotepad : Imho { }

Mixing data and code, the XSLT damage continues

To start with a disclaimer : I am not hindered with much of practical XSLT experience. Mainly a matter of taste. But the technique keeps popping up over and over again. Every book on XML does cover it, there's a component sitting on VS.NET toolbox and a lot of MS apps do use XSLT in some kind of way. More on that later. XSLT is confusing to me because it does mix data and code. Code which was originally meant to format the presentation of the data but can be used to do whatever what. In .net you can even call methods of your own assemblies in an XSLT transform. I do like XML, it gives you a great insight how your data is structured and what it is supposed to stand for.

A part of the talks by master Don on Indigo were on the separation of code and data. An object encapsulates data and has behavior in the form of methods. A message does not have any behavior. An object is a very nice thing to use inside your code as long as it stays in there. A message can be presented to the outer world. That is a clear story separating the two. I understand the sub-title of Don's blog as not to friendly on XSLT either, but maybe it is an over-simplification to lump these two matters. To keep on over-simplifying let's take a small look at XAML. In XAML you can store code in a CDATA section of a XAML file describing a component. Again you are mixing code and data then. Brent Rector takes a very strong stand against doing this in the Longhorn book. But even Don published a snippet where he did mix.

After these theoretical thoughts (flame me out of here if it is bullshit) the actual reason for this post. I bumped into XSLT again where it tried to to something behind the scenes, didn't know how to solve that and presented me with something which had me puzzled for quite some time. Internet Explorer uses XSLT without us noticing it. The result is quite nice when you open an XML file in IE, but the result is a horror when you try to open an aspx file via a local path, not via http. The main menu of an app I'm working on is a plain index.htm, I use Frontpage to try to make it look pretty and use plain hyperlinks to the aspx pages. Works like a snap until you open the file locally. It folllows the link and will try to open the aspx. There is no IIS between the request and the file and what happens is that IE tries to perform a transform and fails.

The XML page cannot be displayed

Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.


A name was started with an invalid character. Error processing resource 'file:///C:/Usr/SU/MOC 1.0/Systeembeheer/Menu.aspx'. Line 1, Position 2

<%@ Page language="c#" Codebehind="Menu.aspx.cs" AutoEventWireup="false" Inherits="Systeembeheer.Menu" %>
-^

I don't blame my local disk for not acting as a an IIS, I do blame IE for this stupid message. A little Googling showed me this does happen in a lot of other scenarios as well. Leaving a lot of people puzzled. And it is a code and data mix-up. But the code was not intended for XSLT but for the ASP.NET web-server.

Blog on,

Peter



Comments

Frans Bouma said:

The errors related to XML in IE are mostly related to the older XML engine IE uses. So it can happen your code is ok, but IE's older XML engine fails.

Furthermore, XSL is not an imperative language, that it performs line n before n+1. It's a pattern matching language like Prolog or Miranda: it matches patterns and when a match is found, the code related to the matched pattern is executed, probably also a try to match something or to select/emit something.

So do not look at XSL as a bunch of forloops or something like that, when you do, you will never grasp XSL.:)
# November 14, 2003 8:57 AM

PeterGekko said:

Thank goodness, no flares :>. I really think I do understand what XSL is trying to acheive. Match a pattern and execute some code when it finds one. But I have seen too much code full of for loops and xslt "apps" trying to do things which can be done far better in "normal" code. My major point if its implementation in IE cannot transform an input stream it should keep its hands off and not raise silly error messages.. And I really dislike the "syntax" of an xslt stylesheet. Give me a class with events which fire when finding a match. Like the xmlreaders. But the latter will be a matter of taste.



# November 14, 2003 1:15 PM

JosephCooney said:

I've used XSL(T) mainly to generate code, but am by no means an expert. Where the output was also XML XSL(T) was great, otherwise it was not really that much better than other languages. IMHO the really good part of XSL is not XSL at all, but XPath. It makes processing XML documents SO much easier. Writing XML DOM code is so much nicer too with liberal use of XPath (altho I might be biased).

I don't really see how XSL mixes data and code. XSL(T) is about transforming XML documents into other XML documents (and maybe non-XML documents too), so it is code, not data. The fact that you can call a method in a .NET assembly from XSL(T) merely reinforces this (just like you might call a stored procedure from .NET code etc), XSL(T) just has a more declarative style while your VB.NET or C# code is more imperative. Including code in an XAML file is mixing declarative and imperative styles of coding, and probably breaking the seperation between presentation and the rest of your application, but XAML is obviously not XSLT either...

Altho Don Box's weblog title might suggest a negative view of XSLT, he does seem to use it sometimes (like for generating the RSS feed for his blog), and he uses Visual XSLT from ActiveState.
# November 16, 2003 4:53 PM

Alex Thissen said:

Hello Peter,

I just stumbled onto this "discussion" and hope it is not too late to make one or two comments on it.
Reading the error message, I thought that it was pretty logical that it should occur. While I am not entirely sure how the aspx is requested, my guess is that you do a client-side transformation using XSLT on the XML retrieved from the aspx page. Am I OK here?
Running the file locally will retrieve the aspx page as is, without it returning the XML stream. When IE then tries to transform the XML, it fails as the aspx page's source code is not well-formed XML. This has nothing to do with the "older" XSLT engine of IE (Sorry, Frans). In fact, IE will (by default) transform using the MSXML 3.0 engine. Depending on the namespace of the XSLT it will use the Working Draft (http://www.w3.org/TR/WD-xsl) or the Technical recommendation instruction set (http://www.w3.org/1999/XSLT/Transform). You can instruct IE to use MSXML 4.0, but you would have to use client-side JavaScript to transform the XML. That's because Microsoft stopped setting the version-independent ProgID's for MSXML to the latest version as of version 4.0. This means that whenever you ask for something like:
Dim obj
Set obj = CreateObject("MSXML2.DOMDocument")
you will get version 3.0 instead of 4.0, if that is installed. The same goes for other MSXML classes. (Oh, and never mind the MSXML2, that's always there after 2.0 and has no connection to the version of the installed MSXML suite)

If you are interested: when IE displays an XML page it uses this XSLT file: res://msxml3.dll/defaultss.xsl
Yes, it does use a Working Draft XSLT. Weird that they never upgraded that.

Hope this restores some faith in XSLT.
# January 1, 2004 9:43 AM

Peter's Gekko said:

# January 6, 2004 3:32 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!