[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Future XSLT extensions. document(). Summary.

Subject: Re: Future XSLT extensions. document(). Summary.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Wed, 22 Mar 2000 13:25:51 -0800
sql request in xsl

Hi,

> Paul said:
> Very interesting.  Could you please tell me what is the syntax
> of XSLT document() you are using to access the database?
>
> Didier replies:
> Steve already posted a way to make a sql request to an Oracle server and I
> am sure he can provide other examples. I just tested the SQL server this
> morning with the following construct
>
> <xsl:apply-templates select="document('localhost/test?sql=select title from
> parts-catalog')/catalog/part">
>
> And then have the style sheet to match the elements contained in the <part>
> element and produce HTML constructs that are further displayed in both the
> Netscape browser and the Microsoft browser. Until Microsoft supports the
> document() function, all processing is done server side. But as soon as
> Microsoft publish a new version supporting the document() function, the
> transformation into HTML will be handled server side for Opera and Netscape
> and client side for Explorer. If at least a third of the browsers are
> Explorer browsers then, my server resources will be less taxed since 1
> request out of three will be handled by the client. Said differently, most
> of the job to assemble the content for rendition will be handled by the
> client, not the server. And again Paul, I am too tired to argue on this, I
> just expressed what experimented and kindly answered to your question. Not
> with the intention to judge your position but to simply express the result
> of concrete experience, not political fighting.

You may be tired, but could you please explain me what do you want
MS to support ?

<xsl:apply-templates select="document('localhost/test?sql=select title from
parts-catalog')/catalog/part">

1.  I don't think you want MS to acess the *clients* localhost ( that's
a huge security hole ) that means what you *realy* mean is:

<xsl:apply-templates select="document('http://myhost/test?sql=select title from
parts-catalog')/catalog/part">

This  is an example of document(URI). It has nothing to do with SQL. The URI
could point to any other GCI.

When this XSLT stylesheet runs inside the MS IE - what do you want
MS to do?

I think the only possible thing MS IE can do is to access the  the URL and receive
the XML in return and then parse that XML into node-set.

I think nobody is arguing with *this* support of document(URI)

BUT.

1. Asking MS to support *this* document() is a *different*  thing
than asking  MS to support the document() as it is described in the
'standard'.

document() is much more than document(URI).

2.
There is another view on this problem, that instead of making HTTP request
to the URI, XSLT engine should get the *node-set* as-is.

This view equals to:

"Why using XML, it is not effcient - CORBA is better".

Could you please re-read the XSLT description of the document() function
and explain what in particluar do you want MS to support ?
What if they'l support only document(URI) ? ( I'm sure they'l anyway do
that earlier or later, the question is do they need to support *more* than
document(URI) - and the WD asks for *more*).

Rgds.Paul.



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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.