[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: alternating tags in a list?

---

---

Hi Paul

thread 1---------------------------------
Didier PH Martin wrote:
>
> the problem is with the <action> part. Theorists see no problems but
> pragmatist see problems of flexibility.

I think that there are two misunderstandings in this part of your post:

It isn't theorists versus pragmatists. I'm helping a company with terabyte
databases implement a million-hits-per-day XSL delivery system. If that
puts me in the "theorists" camp then who is in the pragmatists one?

The real distinction seems to between those who value convenience over
scalability (reliability, performance, etc.) Flexibility is not at issue:
the need for scripting languages on both client and server is absolutely
understood by all. I spend most of my life working in a scripting
language. The question is whether the scripting language should be a
separate layer or the same layer. You seem to agree that it should be a
separate layer, so I guess that makes you a "theorist."

Reply --------------------------------------
Sorry if you understood this. I didn't meant to call you a theorist. It is
only, that the general tone (not necessarily what you said) from people
doing stuff calls for such extensions. I don't really know the reasons, but
this seems to be a trend. Most arguments against providing access to
procedural languages (like ecma script for instance) where invoking putity
of design ( an other trend). Ouff, with more training Paul i maybe could
become a lawyer :-))

Thread 2 -----------------------------------

> So then, why not have the <action> part defined as a script then?

That's what DSSSL does.

Reply -------------------------------------
I agree.

> You are right, the visitor pattern could be done in each of these
languages.
> However, if that is done for you, it means less work isn't it ;-) And I
> don't see the relationship between Microsoft dependencies and a schema
like
> suggested ??


thread 3 ----------------------------------
My point is that I am not familiar with any cross-platform technology that
allows arbitrary scripting languages to be plugged into any application.
Typically, you must either use Windows' Active Scripting stuff, or you
must plug in each scripting language to your framework individually.
Plugging each language in is probably the same amount of work as
implementing the framework in each language.

reply -------------------------------------
there is no real multi-OS technology for scripting. However, whatever the
reason for, at least for script engines running on Intel provide the same
Vtbl interface. Let's call that the facade pattern ;-). So, you can easily
re-use these four script engines on Linux if you want as long as you find a
way to bind to a vtbl. The limitation to transportability, in that case, is
more the CPU type than the OS.

demonstration:
OS like Linux or Windows provide 'C' binding to librairies or system
modules. Just look at function call frames and you'll notice that it is in
fact a C function call. Some systems like MacOS are based on a Pascal
function call convention. New windows modules provide a C++ vtbl binding
(i.e. virtual pure). Some work in progress in the Linux family is around the
same C++ VTBL binding. Thus, script languages like Perl or Python could be
re-compiled on other CPU type and provide the same vtabl binding. Here you
have a transportable schema based on c++ binding instead of c bindings. What
wrong with that? Maybe that it wasn't invented in Sun's lab ;-) If we take
apart all market share games (or legal games) and just consider what's
invested yet. We have at least two public domain script languages having
this kind of interface. The third one (free ecmascript) could be easily
adapted too. We call that leveraging what's there. Thus, IactiveScript or
IActiveScriptParse could be seen as:

1 - C++ interfaces (virtual pure members)
2 - COM/DCOM interfaces
3 - Devil's product :-))))

Let's forget the last two and keep the first one then you may have a
platform independant interface. you can do it with GNU.
end of demonstration:


Thread 3 ----------------------------------
Anyhow, implementing an XSL-like pattern->action pattern is quite logical
and should take the pressure off of XSL to be the be-all and end-all
replacement for ASP, DOM and everything else.

reply ---------------------------------------
Right on! XSL is a language with its limits and stength. It seems that it
don't provide an good answer to all developers needs. Maybe it is of its
basic premises. Anyway, are learning in the process as we learned from DSSSL
(and still do).

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


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

---