RE: [xsl] xsl:sort in old MSXML

Subject: RE: [xsl] xsl:sort in old MSXML
From: "Claudio Russo" <crusso@xxxxxxxxxxxxxxxxx>
Date: Wed, 2 Jul 2003 14:37:00 -0300
Oops! Finally I've got your attention! (you where the first one addressed in my first mail regarding the issue).

Yes. Everything is clear, and arrive to this with the previous messages from Davids, Wendell, Oliver and Jim. I appreciate very much all the efforts they made to understand this. 

It happens that while reading the incoming msgs in the list, I wondered why, if a standard was on, while all so many people were having so much trouble deploying (me too) XML/XSLT transactions. For those as you guys, who have really clear all these flavours maybe looks pretty easy, but it doesn't look so for the rest. That's why I wondered if there was any place to see a graphic or so to understand the whole architectural schema, and which is the best way to move forward. I can do, as somebody said, look at the example, try and fix (which I already did), but I guess there's no need to reinvent the wheel when you already overcome all these issues.

Regards, Claudio.

-----Original Message-----
From: Michael Kay [mailto:mhk@xxxxxxxxx]
Sent: Miércoles, 02 de Julio de 2003 01:38 p.m.
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] xsl:sort in old MSXML


> 
> So, what should I need this Saxon if it all depends on IE6 or 
> Mozilla to run the XSLT that I typed using a standard txt 
> editor? Wouldn't be processed by its standard processor (eg: 
> IE6 --> MSXML3; Mozilla --> I don't know; Nestcape 7 --> I 
> also don't know).
> 

I'm having trouble working out what it is that's confusing you. Several
people have tried to explain this to you, and it's very simple, but
somehow the message hasn't got through.

You start with a file of XML.

You run an XSLT transformation that takes this XML and a stylesheet as
input, and produces a file of HTML as output.

You send this HTML to a browser.

The browser turns the HTML into pixels on your screen.

The XSLT engine can be integrated with the browser. In this case you
never get to see the HTML, you only see the final pixels. This is called
client-side transformation. It generally needs an XSLT engine from the
same supplier as the browser (Using Java applets is theoretically
possible but not widely practiced).

Alternatively you can use an XSLT engine that is quite separate from the
browser. In this case they are usually run on different machines. This
is called server-side transformation. They do not have to run at the
same time (you can do the transformation in advance, at publishing time,
and store the HTML on disk). And the XSLT processor doesn't have to come
from the same supplier as the browser, because the all that the browser
sees is an HTML file, and it doesn't even know that it was produced as
the output of an XSLT transformation.

Is this any clearer?

Michael Kay


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread