Re: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file)

Subject: Re: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file)
From: Ray Cromwell <ray@xxxxxxxxxxxxxxx>
Date: Wed, 11 Nov 1998 11:55:54 -0500 (EST)
> Don't talk of things you obviously don't know with such assurance. Make your
> classes before. What you say is wrong. I'll say no more comments than that.
> Your mid is obscured by your wholly war. This is a waste of efforts to
> further discuss this issue.

  You're right, I don't know. But the last time I looked, the only
DCOM products I saw were bridges. And most of the people who
who use DCOM seem to be using MTS on an NT server as the middleware
to login to a datasource on a legacy machine. My question is, is
there an MTS server available for other platforms besides NT?

(besides, I have seen articles saying that both MTS and EJB have
trouble scaling beyond a few hundred sessions, contrary to
Roger Sessions's comments)

  With the existence of bridges, DCOM vs CORBA doesn't really
matter much. The real question seems to be MTS vs EJB vs proprietary
object/tp monitors. 

> > People who want to use XSL to build documents from databases directly
> > are too hooked into the ASP/ColdFusion template mindset where one
> > defines an an incomplete HTML document and fills in the holes via a DB
> > query in VBScript or ColdFusion tags.
> 
> No necessarily, just try to compensate for inherent system weaknesses and
> tight delivery dates.

If I had a tight delivery date, I'd take a least tech approach
and implement the whole thing using ASP/PHP/JSP. On the other hand,
if you are using server side only xsl and you will never distribute
the xsl files, I don't see a problem using a few proprietary extensions 
either.

> > My own preference is for a simple RDBMS-to-XML mapping language that
> > takes queries and spits out fragments of XML which can be Xlink-ed
> > into another document. You author your XML documents normally, but
> > when you need to include dynamic data, you XLink it in. Performance
> > may suffer, but caching solves the problem.
> 
> When you deal with thousands of clients, performance is an issue ;-)

 I think this is an idea that needs to be discussed, or, a commercial
company needs to tackle it. For instance, a fast XSL processor
could probably mark dynamic parts of the XML input, and cache
the static parts. It could then simply transform only the dynamic
fragment (which is valid XML)  Better yet, you coul use a separate XSL
stylesheet for the dynamic fragment.

Another comment. I've been experimenting with IE5beta2 and
the XSL stuff seems to work very nice on the client side. So
does XML+CSS. Too bad it will be 2 years before I can depend
on a huge segment of users having this capability. :(

-Ray


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


Current Thread