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: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Wed, 11 Nov 1998 10:48:27 -0500
Hi Ray,

> First, it seems to me that if you have to link with legacy mainframes,
> DCOM certainly isn't the way to do it. What do you think is more
> likely to exist on mainframes and minicomputers -- a CORBA
> implementation or a DCOM implementation? I'd expect CORBA from IBM,
> not DCOM.  COM has its uses as a component model, much like JavaBeans,
> but when all you want is distributed interfaces, I'd say that on
> legacy systems, CORBA is alot more mature and available.

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.

> Secondly, I think doing database queries inside the XSL processor is just
> WRONG.  It totally breaks the architectural design IMHO. XSL should
> not be in the business of querying a database and building a document.
> To me, in the model-view pattern, XML is the data model, and CSS/XSL
> are the "view" Any RDBMS/OODBMS/LDAP/IMAP/SearchEngine/whatever
> queries should be done and already inserted into the XML before
> XSL even sees it.
> If XSL has to perform any dbms queries, it should only be used to change
> the look-and-feel (personalization), not the data. An example
> architecture is
> +------+
> |OODBMS|------\                           optional query
> +------+       \                           to personalize view
>                 \                               |
> +-----+          \ +-----------+           +-------+
> |RDBMS| -----------|XML results|---------->|CSS/XSL|--->
> HTML/PDF/Whatever
> +-----+           /+-----------+           +-------+
>                  /
> +------+        /
> |Custom|--------
> +------+

Your point is clear. I think that on this issue, you set very well the
limits of what this transformation language should do. After more thoughts,
I should say that you are right. XML is the model and XSL not the view
however but a transformation language to obtain the view. The goal now is to
see if the language is complete enough to allow all the kind of views that
we need. I'll continue my classes and test the limit of the transformation
language. I did it already with DSSSL, I'll do it with XSL. So, thank you
for your comment, it is well taken.

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

> The problem with using XSL for this approach is that at no time is
> there ever a complete valid XML document. If you simply invent your
> own static tags in XML and have all dynamic data "filled in" at the
> XSL level, than a user can never get his hands on an XML document
> containing the untarnished data.  What's the point?  If you use XSL
> like this, what does it buy you that PHP, JSP, ASP, LiveWire,
> ColdFusion don't? You aren't putting any data in the XML, just using
> XML tags like neat little macros that expand into HTML chunks.

Right, XML is the model and XSL a transformation language to obtain a view.
OK. We'll do experiments to see if we can obtain the kind of view we need.

> 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 ;-)

> This approach works very well for the 90% of common website functions
> like providing news bulletins (ala miniportals/aggregrators),
> doing a catalog, or a portal-tree, or even providing web chat forums.
> The advantage is, the XML documents can be retrieved by the client,
> indexed, transformed, etc.

Yes, your point is: create a transformation module to transform backend
stuff into XML and then transform that again into something else with XSL.
Make sense from a architectural point of view but not necessarily fast isn't
it? In a perfect world this could make sense, however, you may have often
the following situation:
 -> static text in XML format (was only couple month ago in SGML format, but
suddenly we discovered that it is now in XML format) + data stored in data

The goal: build a document that can be rendered on front end clients (i.e..
browsers). If the server has to serve thousands of clients, performance is
an issue. The more transformation you do, the more you degrade performance.
Of course you can add new processors, Isn't it what Microsoft is creating
sometime with bloatware? Think about that and put yourself in the shoes of
mission critical systems with thousand of users where _performance_ is an
issue. Not only that, delivery time to. What's nice about transformation
language is the increase productivity compared to other language. Even
compared to Perl, XSL is more code efficient for certain transformation

Like everything, as always: "think like a man of action, and act like a man
of reflection" Paul Valery.

> All IMHO,
> -Ray
>  XSL-List info and archive:

 XSL-List info and archive:

Current Thread