XSLT -- some basic info needed

[Ringo Langly]

Hi all,

I'm a seasoned web programmer, but I've never touched XSLT. It's
always been one of those acronyms I've never needed to educate myself
on.

Now... we're working with a web content provider who says we need to
use XSLT and Web Services to pull the content from their site. Can
someone give me a nutshell definition on how this works??? We use
Cold Fusion MX on our web server, but I'm having trouble finding a
somewhat simple procedure on how one pulls data from a remote server
using XSLT. If nothing else I need to know what we need from the
content provider to pull data from them, and maybe some example code
or websites with more details on how this process works.

Thanks in advance...

- Ringo -

[Patrick TJ McPhee]

Re: XSLT -- some basic info needed

In article <7d96e89e.04072 21331.29ee35b@p osting.google.c om>,
Ringo Langly <rlangly@gmail. com> wrote:

% Now... we're working with a web content provider who says we need to
% use XSLT and Web Services to pull the content from their site.

You might need web services to pull the content. XSLT is (mostly)
orthogonal to retrieving data. It is used to restructure the data
once you've got it.

I say mostly, because you can retrieve data remotely using the document()
function

document('http://www.stupid.prov ider/content')

but ordinarily one has the data, runs XSLT over it, and then uses the
results.
--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Berislav Lopac]

Re: XSLT -- some basic info needed

Ringo Langly wrote:[color=blue]
> Hi all,
>
> I'm a seasoned web programmer, but I've never touched XSLT. It's
> always been one of those acronyms I've never needed to educate myself
> on.
>
> Now... we're working with a web content provider who says we need to
> use XSLT and Web Services to pull the content from their site. Can
> someone give me a nutshell definition on how this works??? We use
> Cold Fusion MX on our web server, but I'm having trouble finding a
> somewhat simple procedure on how one pulls data from a remote server
> using XSLT. If nothing else I need to know what we need from the
> content provider to pull data from them, and maybe some example code
> or websites with more details on how this process works.[/color]

The idea is this: you remotely call a function on their server, basically in form of a Web URL with a few parameters, or by sending a XML-formatted request (this is the gist of the term Web services: XML-sdandardized remote procedure calling). They respond with some data, again formatted as an XML standard (usually SOAP or XML-RPC). It's very likely that the format you receive it in won't be appropriate for your needs, and then you use XSLT to process it into another format you prefer, either XML (for further processing) or HTML (for direct display).

Berislav

[Andy Dingley]

Re: XSLT -- some basic info needed

rlangly@gmail.c om (Ringo Langly) wrote in message news:<7d96e89e. 0407221331.29ee 35b@posting.goo gle.com>...
[color=blue]
> I'm a seasoned web programmer, but I've never touched XSLT.[/color]

You should do - it's useful stuff.

How's your XML ?
[color=blue]
>It's
> always been one of those acronyms I've never needed to educate myself
> on.[/color]

The Michael Kay book, "XSLT".

The O'Reilly "XSLT Cookbook", if you find yourself dropped into
something from a great height, but be warned that it contains major
ugliness ! XSLT is one of those technologies that's beautiful when
it's applied to the right problem, but often mis-applied and
blecherous.

[color=blue]
> Now... we're working with a web content provider who says we need to
> use XSLT and Web Services to pull the content from their site.[/color]

You _need_ web services. You may find XSLT useful.

You may also find XSLT to be a nightmarish hell-hole (especially with
web services), but that's a separate issue. It is _not_ the solution
to all the world's data integration problems, so be suspicious of
vendors who tell you it is. But you should still learn it.

[color=blue]
> Can someone give me a nutshell definition on how this works???[/color]

In the beginning was Unix RPC RMI, Corba, DCOM et al. These let you
"call functions" on distant machines. Then the philosophical question
started to arise as to whether it was best to treat these as
"functions" ; placeOrder (myOrder) or to treat them as wandering
objects that could manifest behaviours in the relevant places;
shippingWarehou se => myOrder.fulfill Yourself

HTTP and the web happened. Shortly followed by HTML and gaffer tape.
It was extremely useful to "screen scrape" catalogue sites and read
the human-readable HTML version, instead of doing a database import of
the products catalogue. You could even pretend to be a
human-filled-out <form> and submit orders from scripts. Great advances
in usefulness, but oh was this code nasty and unstable!

So in '99 or so, SOAP arrived. Take XML (as a better-behaved and more
flexible HTML) and use that instead, through something resembling a
well-thought-out specification. XML-RPC was also invented (by He Who
Shall Not Be Named), but that's best ignored.

SOAP used HTTP, because everywhere in the world was wired for HTTP and
firewalls let it through unchecked. If you couldn't do this, you could
run it over SMTP (rather cute for low-volume and low-cost setups) or
any other protocol you could invent. I'm sure someone on Slashdot has
done carrier pigeons and Napster by now.

That question of "function call vs. wandering object" cames back
again. SOAP specs went through minor version changes and came back
unrecognisable. Hmmm.

By this time, SOAP was getting unwieldy. Its one great benefit though
was its _absolute_ non-proprietary nature, platform and coding
language independence. So then along came "web services" and the rise
of middleware. This "simplified " things for developers, because now
they had a piece of code on their machine to take to, rather than an
abstract protocol. However we were also now tied to vendors (IBM
Webthing, BEA Webotherthing or briefly HP's Bluestone) and languages
(Java everywhere on all servers). OTOH, imagine the tag soup nightmare
if developers still in short trousers had to write their protocol
state machines. At least now it works.

To let web services talk, there's something called WSDL. This is like
IDL for web services, it describes function call APIs. Most
service-building people now make WSDL (automatically, so it's fairly
accurate) and a few client-building people even use it (also
automatically).

UDDI is the next rung up the tree. This lets you advertise web
services, so that clients looking for "a service that does <foo>" can
find one, even if they've not encountered your business before. No one
uses this yet.

M$oft did something too, but we don't talk about .that
BizTalk is evil incarnate, BTW. First M$oft product to be specifically
mentioned in the Book of Revelations.


So now it works like this.

- Buy middleware, as suits your existing server platform (or switch
to JBoss). All middleware talks to all other middleware - any that
doesn't is a heretic and should be burned.

- Design your app, probably using some sort of CASE tool. Press a
button - out pops both code that talks to your middleware, and WSDL
that describes its web service nature.

- Plug. Play.

- Pay large bill for middleware.

- Pay larger bill for Java geeks who understand optimisation.


The O'Reilly on SOAP is almost useless because it's so trivial, but it
is a reasonable one evening's read that will give you the basics. Then
throw it away.

More advanced reading really depends on which platform you've chosen.
The grey one with the zen garden on the front is decent, if you're not
already anti-Java.


[color=blue]
> We use Cold Fusion MX on our web server,[/color]

Haven't touched Cold Fusion this millennium. All platforms have a
middleware product though, becuase if they don't, then they're dead.

[color=blue][color=green]
> >but I'm having trouble finding a[/color]
> somewhat simple procedure on how one pulls data from a remote server
> using XSLT.[/color]

You don't.

You pull the content by other means (probably "Middleware for CF"),
then you get an XML document back. You might process this by XSLT.
That would rather depend on what you intended to do with it afterwards
though.

If I was writing a client that used a consume-only model with some
fairly detailed information service (maybe TV listings), then I
offered this to humans through something like HTML or PDFs, then I
would look at using XSLT (largely because the final consumers are
humans who like verbose documents). If I was doing something more
machine-oriented, or more bi-directional, then I would avoid XSLT.

[Deirdre Saoirse Moen]

Re: XSLT -- some basic info needed

Ringo Langly <rlangly@gmail. com> wrote:[color=blue]
> I'm a seasoned web programmer, but I've never touched XSLT. It's
> always been one of those acronyms I've never needed to educate myself
> on.[/color]

XSLT formats stuff, but it is content-dependent. It's much more like
working with prolog (or any rules-based AI, really) than like working
with C/PHP/etc. It's supposed to be non-linear.
[color=blue]
> Now... we're working with a web content provider who says we need to
> use XSLT and Web Services to pull the content from their site. Can
> someone give me a nutshell definition on how this works??? We use
> Cold Fusion MX on our web server, but I'm having trouble finding a
> somewhat simple procedure on how one pulls data from a remote server
> using XSLT.[/color]

Are you formatting the resulting output with XSLT (i.e. pulling XML,
then transforming it?) or are you pulling XSLT itself?
[color=blue]
> If nothing else I need to know what we need from the content provider
> to pull data from them, and maybe some example code or websites with
> more details on how this process works.[/color]

--
_Deirdre web: http://deirdre.net blog: http://deirdre.org/blog/
"Memes are a hoax! Pass it on!"