This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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




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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]