RE: alternating tags in a list?

Hi Keith,

You said:
ASP is not the only web-based server development environment out there.
Netscape uses LiveWire (Server-Side JavaScript)...and almost any server
can support Java Servlets.

Write your LiveWire or Servlet or ASP application to access your
relational database. If you wish to leverage XSL you can turn your query
results (tables) into an XML document and then run the XML through an
XSL processor using a specified stylesheet.

Reply:
First part of the comment is right and because its a matter of fact we can
add also the roughly 20 to 30 products on the market that does the same
ting. Nothing more to say here

the second part is probably targeted to a light trafic server. If that is
the case, nothing to say here. If, at contrario, it is not the case and ww
have to do an implementation on a high trafic server, this is a very bad
idea.


You said:
I don't see XSL as a threat to ASP or as competition to ASP. XSL is
meant for "styling" an XML document. Its not meant to be a web-based
programming environment. I do feel that scripting should be allowed in
an xsl stylesheet, but only to access the relevant objects. Relevant
objects would include the source tree or result tree. Scripting should
also provide some additional computing power such as mathematical
expressions which gets back to how this thread ("alternating tags in a
list?") started.

I feel that the following should be allowed (the "this" keyword
references the current "source" element that is being processed,
"number" would return the position of the given element):

...
<xsl:template match="employee">
 <TD>
 <xsl:process select="name"/>
 </TD>
<xsl:script>
 if ((number(this) % 2) == 1)
   return "<![CDATA[</TR><TR>]]>";
 else
   return "";
</xsl:script>
</xsl:template>
...

I don't think the next example should be allowed, it really has nothing
to do with XML or XSL other than using XML elements for specifying my
actions, and I think this is what you two are suggesting:

...
<xsl:template match="/*">
<xsl:script>
   var connection =        Database.getConnection("ORACLE",
"beq-local","myuser","mypass");
   var query = "SELECT * FROM exmployees";
   var cursor = connection.cursor(query);

   while (cursor.next()) {
      write(cursor.name);
   }
</xsl:script>
</xsl:template>
...

Reply:
You point is: let's keep the XSL as a stylesheet language. OK
My point is: We have an oportunity here to have the language to be used
either on the server or the client. if we can run the second example, _and_
if we have an efficient XSL interpreter, we have then a chance to have a
language that could be used on the server _that_  _can_ do the same work as
a ASP page (I know you can do that with.... I picked ASP just as an example,
replace ASP by the acronym of you choice as long as it does the same task).
If we then have such language on the server we may have a chance to have a
common server side scripting tool and not be locked in any proprietary
solution (said differently, you can _choose_ the best vendor not being
locked to only one. Isn't it what a competitive environment should be
doesn't it?).

So if you use your second example + the fact of being able to use templates
you have the same functionality as you get with asp. It is just a little
step further and won't scrapt the XML construct _that_ should be enough
versatile to allow assembling constructs in a coherent whole.

Don't forget that in the _real_ _world_ we even have to connect to
mainframes!!! and that a lot of data, especially for e-commerce is resident
on SQL servers not being stored in XML document. Maybe, one day a sql
request will return a XML document _but_ we are not there yet.

In fact, your second example just showed that such link with actual legacy
data could be possible within the XSL framework.

>From an other point of view, you first example just showed
a) an ineficient way to use server resources (if you have a very loaded
server you _should_ know of what I am talking about)
b) that legacy data access is not part of the answer provided by XSL.

thus, to replace ASP (or any other kind of proprietary solution) by XSL, we
can imagine a short XML document used as bootstrap to start a XSL script
that will construct the right document (or the XSL interpreter on the server
could simply consider a phamtom XML document). This is a server side
solution.

When, evebody on earth will have a client side XSL interpreter, we may
envision different scenario. But, this will not append overnight! Why not
consider the current state of the Web instead of dreaming of the perfect
world. Utopia is fine but there is a here an now that we have to cope with
and a process to go from now to then and from here to there. OK for the then
and there and a perfect XSL not poluted by the actual state of the art. But
what about the here and now?? and how to get there? where are the steps?

Or maybe we should let XSL as is and let a manufacturer listen to request
made by developers, do a good job at it and give what they want. Then let
the others cry to daddy governement that this guy stoled all the toys in
town :-))))

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


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