XSLT -- some basic info needed

Discussion in 'XML' started by Ringo Langly, Jul 22, 2004.

  1. Ringo Langly

    Ringo Langly Guest

    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 -
    Ringo Langly, Jul 22, 2004
    #1
    1. Advertising

  2. In article <>,
    Ringo Langly <> 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.provider/content')

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

    Patrick TJ McPhee
    East York Canada
    Patrick TJ McPhee, Jul 23, 2004
    #2
    1. Advertising

  3. Ringo Langly wrote:
    > 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.


    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
    Berislav Lopac, Jul 23, 2004
    #3
  4. Ringo Langly <> wrote:
    > 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.


    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.

    > 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.


    Are you formatting the resulting output with XSLT (i.e. pulling XML,
    then transforming it?) or are you pulling XSLT itself?

    > 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.


    --
    _Deirdre web: http://deirdre.net blog: http://deirdre.org/blog/
    "Memes are a hoax! Pass it on!"
    Deirdre Saoirse Moen, Jul 23, 2004
    #4
  5. Ringo Langly

    Andy Dingley Guest

    (Ringo Langly) wrote in message news:<>...

    > I'm a seasoned web programmer, but I've never touched XSLT.


    You should do - it's useful stuff.

    How's your XML ?

    >It's
    > always been one of those acronyms I've never needed to educate myself
    > on.


    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.


    > 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 _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.


    > Can someone give me a nutshell definition on how this works???


    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;
    shippingWarehouse => myOrder.fulfillYourself

    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.



    > We use Cold Fusion MX on our web server,


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


    > >but I'm having trouble finding a

    > somewhat simple procedure on how one pulls data from a remote server
    > using XSLT.


    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.
    Andy Dingley, Jul 23, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vasanth
    Replies:
    0
    Views:
    529
    Vasanth
    Jun 28, 2004
  2. Andrea Williams

    Clear the Render info & change to different info

    Andrea Williams, Oct 27, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,398
    Ken Dopierala Jr.
    Oct 27, 2004
  3. Replies:
    3
    Views:
    371
    Peter Flynn
    May 27, 2005
  4. Kiran
    Replies:
    0
    Views:
    1,206
    Kiran
    Feb 6, 2005
  5. Ikke
    Replies:
    0
    Views:
    343
Loading...

Share This Page