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

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

HI Ray,

you like black and white worlds, do you?

The reality is a bit more complex than you expose it. First, DCOM and is
first and foremost an binary interface standard based on C++ vtables (for
early binding) and a late binding convention (IDispatch). Most DCOM products
are not necessarily all MTS product. What about a 300 millions  component
industry? :-)

If MTS is a good product or not, I let people judge by themselves and I
personally think that this mail list is not the place to bitch on Microsoft
or any other manufacturer but to talk about XSL issues. So choose an other
platform for your jihad. Understood?

The whole point here is: if the script extensions are  the standard, any
other manufacturer can respect the specs and provide a fully compliant XSL
interpreter. Otherwise, the manufacturer has to create proprietary
extensions and we are then again at the same position that we are now - no
choice.

On one side a manufacturer with deep pockets that, at least listen to
developers needs
on the other side religious thinking trying to impose their view of the
world.

What we just ask for is only that the specs could be revised (version 2 or
discussed) to include a standard way to include scripts. So, for instance,
Koala could choose to implement it. If the industry agree that specs
compliance need to include at least ECMAScript, its OK and then Koala can
include it. The end result: freedom of choice because of a common standard.
We have only to pick the best implementation. The final spec may be
different than what Microsoft is proposing, no problems as long as there is
a way to get a better tool.

Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Ray Cromwell
> Sent: Wednesday, November 11, 1998 11:56 AM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Re: Microsoft extensions to XSL (was RE: how to call Javascript
> function in .xsl file) function in .xsl file)
>
>
>
> > 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
>


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