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 Tyler,

Simple question. Did you created something with DCOM?

We are working with both since 4 years now (COM at that time and a beginning
CORBA). I don't think that CORBA is superior like you say, only that CORBA
and DCOM are different having each one strength and weakness. A weakness
example of DCOM. Actual security is NT only. Actual strength, you can bypass
it by replacing the marshalling. CORBA strength: object inheritance, CORBA
weakness object cannot have multiple personalities accessed through a query.
So I personally think that both object middleware should take the good
things of the other. One thing remains, both are independent of languages
and take a architectural approach to design, which is a good thing, remember
the facade pattern (Gamma and al.) with interfaces you can have more than
one implementation sharing the same interface. This is what we have with
script engines.

So, come on, beyond the wholly war there is serious thinking. Each time,
someone is doing statements like that is like saying the earth is flat
without taking a boat and trying to see if that is true. Don't mix business
practice of a horde of barbarous people with technology which could be
evaluated as objectively as we can. Is it how we made progress in sciences?

So the point here is. Something is missing, a tag definition for scripts. It
is possible to have more than one script. the suggestion that we have a
standard script as default makes sense. However to be able to choose one is
a plus. Actually, any XSL implementation able to use these DCOM (which are
in fact C++ Vtabl when used in process - a certain progress to "C" dll
doesn't it) object could in fact support more than one language and this has
nothing to do with Microsoft. Perl is not made nor owned by Microsoft, so is
Python. If people use DCOM it is not to support Microsoft, it is a practical
solution with good technical points and weakness . Just ask Perl or Python
implementers. If Netscape proposed a good "in process" interface mechanism,
we could see also different implementations. But maybe the best location for
such feature would be on the server not the client.

About XML mutation - don't forget that XML is a language to design
languages, so wait a couple years and count how many languages are derived
from XML. History will speak.

About XSL not being a language - What is your definition of a language then.
Come on, don't take us for fools. What about a transformation language?

If XSL should not include other languages. It is maybe controversial from a
philosophical point of view but quite particle in fact. A strong point of
any XML derived language is that you can include more complex constructs so
why not include a script? For religious person that should not include a
script in their XSL, let them live as they wish and respect their
principles. But for others with real practical stuff to do, why not let them
include script in an _ordely_ manner. Does diversity sound like something to
you? I am wrong to say that one goal of XML is diversity of languages
derived form it? If it is not, we do everything to let that happen.

Is it worse to let some include scripts in a transformation language than
everybody define their own language with XML than letting ?

Is it because Microsoft did it that you suffer so much? so, why not define a
standard not owned by Microsoft. XSL has to not say how to implement these
script language, just how to invoke them.

Finally, to change from one dictator to an other is not necessarily freedom.
Java is owned by Sun and the whole platform has not the same status as Linux
or Appache.

And about Netscape, maybe they didn't got enough money which is sad, to
improve their architecture to have it more "component" aware and be less
"big application". their open process is not as open as Linux or Appache so,
I guess that Navigator won't see the same evolution as these guys got.
Should I remind you that these project just took what they found is either
useful or good on the other platform and included it. This is evolution.

Wholly war, do not produce good minds, just dead bodies, you know.

So, if someone from the W3 XSL group is participating to this list (Is W3
open? R: is membership free? are discussion openned? Is IETF opened Yes, is
particiaption free: yes, so we have to deal throught the elite it seems,
like in politics), can we influence the process? could we prevent that
Microsoft give us what we need and be locked again solely on their platform,
only for religious reasons... silly.

By the way tyler, the Javalobby stuff is quite impressive and well done.
However, most of us has to do more complex sites, like for instance provide
e-commerce and link to mainframes (yes, these prehistoric beast are still
alive), link to relational database, etc. XSL is great in a way that it
provides a good transformation language, javascript is not so efficient for
that task. But XSL is not able to link to database and build a document from
data stored in these beast. And if a standard can help us to do that, we
won't get locked into any religion either called Microsoft or Java. I hoped
that people from W3 beyond all religions heard this request from people
having to _deliver_ stuff.


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 Tyler Baker
> Sent: Tuesday, November 10, 1998 8:35 PM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Re: Microsoft extensions to XSL (was RE: how to call Javascript
> function in .xsl file) function in .xsl file)
>
>
> Didier PH Martin wrote:
>
> > Hi,
> >
> > If the goal is to have any kind of script language supported,
> then there is
> > a high probability that Microsoft will allow (if that is not already the
> > case) to interchange script languages. In fact, Perl, Python,
> JavaScript,
> > VBScript all can work within a web page , in Windows Scripting
> Host or in
> > ASP pages. This is because, within the Microsoft's component
> architecture
> > all these script engines support the same interfaces. Remember
> that DCOM is
> > not Microsoft specific, their implementation on windows is. For example
> > Software AG owns the implementation on several Unix, the Linux group own
> > (sort of) the implementation on Linux. So, because Microsoft
> took from the
> > beginning an open architecture for script languages, I don't see why we
> > should associate Microsoft with a strict JavaScript aka ECMAScript
> > implementation.
>
> Yah, but DCOM is an abomination.  CORBA for all its flaws is a
> far superior
> solution to DCOM.  Why anyone would want to use DCOM other than
> to promote MS
> tools, is foreign to my understanding.
>
> > In fact did anybody tried to call an other script engine from
> Microsoft XSL?
> > like for instance VBScript or PerlScript? Maybe it is already in place?
> > maybe their name space can resolve script engine switching.
> >
> > Let's experiment with it. And if that is the case, it remains
> now to work on
> > the tag stuff. i.e. script invocation.
> >
> > In HTML you can invoke (not on all browsers :-( a script engine with a
> > property specifying the language. So, the specs should then specify what
> > property type and value to set. Obviously, Microsoft has all
> the interest in
> > the world to support also VBScript doesn't it? And again, because of the
> > script engine architecture, it will also support PerlScript,
> PythonScript
> > and the other engines supporting the same interfaces.
> >
> > Thus, the problem is not so much Microsoft than the lack of
> specs on this
> > side ;-)
> >
> > And I agree with an other participant that when you try to do practical
> > things, XSL is insufficient. Script support and a DOM is essential to
> > compensate for what is missing in XSL (Don't try to redo an
> other PL1 after
> > all that time we should have enough experience not to redo the
> same mistakes
> > doesn't it? ). And if we can use either PerlScript,
> PythonScript, VBScript
> > or JavaScript to start with, we are then in a better position
> to real stuff.
>
> I seriously disagree here.  XSL is not a programming language.
> If it evolves
> into something of a real programming or scripting language then
> everyone might
> as well just use Javascript, Java with servlets, or any other
> scripting solution
> to do everything.  I think there is an unfortunate perception out
> there that XSL
> is supposed to do every type of content processing imaginable
> both on the client
> and server side.  If XSL turns into a bloated spec, there is no
> reason to use it
> as there are already products like Cold Fusion which do all of
> what XSL does and
> more.  XSL I feel should be simple and geared somewhat towards
> the end-user.
> Some companies I am sure would like to embrace and extend XSL for
> their own
> selfish purposes, so I pray that this never happens.  Thank god
> that XML has not
> been mutated very much by software vendor politics to date.
>
> > My machine already has PythonScript, PerlScript, JavaScript and
> VBScript.
> > I'll try to see if with IE 5.0 I can invoke a script engine
> other than the
> > javaScript engine. remember Bacon, nothing like experiment. A
> lot better, in
> > fact, than playing bad guys good guys ;-)
> >
> > Question for who knows. Why Netscape after some years on the
> market do not
> > support more than one script language? any reason? Just curious to know.
>
> Probably because despite the fact Netscape Communicator is quite
> guilty of code
> bloat, I think the engineers at Netscape at least have some
> concern for not
> turning Netscape Communicator into another MS Office monstrosity.
>  I cannot
> think of one Microsoft product that is what I would call compact
> and concise
> from an engineering standpoint.  All in all, I think Netscape is
> wise not to
> support every programming idea known to man.  In particular, the
> idea not to
> directly support Java in the future may be a good thing with the
> advent of the
> Java plug-in and the so called Open-Java API.  Working to make
> your product
> interoperable with other vendors benefits everyone but the
> software monopolies.
> Microsoft on the other hand has been guilty in the past of "embracing and
> extending" other technologies and I am afraid that may be the
> motive with XSL.
> It would be nice if there was a public statement by Microsoft
> that they will not
> work to own the XSL spec as so many people seem to fear.
>
> As far as XSL technically is concerned, a client I have is very
> happy with the
> current XSL draft as is and they have been able to do lots of
> neat things with
> it on the server side.  Check out http://www.javalobby.org as it
> dynamically
> generates pretty much all of the content dynamically using
> servlets, XML, and
> XSL.  It is very fast on the server side and most people that
> have seen it are
> very impressed that it uses such bleeding edge technologies as
> XML, DOM, and
> XSL.  Currently the technologies the product they have that runs
> the site uses
> XML 1.0, the current DOM implementation, SAX, and of course XSL
> as well as some
> Java specific stuff like JDBC and Servlets.
>
> Note: on the client side unfortunately the home page has way too
> many tables and
> too much JavaScript so rendering the tables in the browser can
> sometimes take a
> second so don't be concerned with the server-side performance.
>
> All engineers are guilty from time to time of trying to solve programming
> roadblocks with hacked up patches instead of spending a little bit of time
> sitting back in a chair and trying to think of an elegant solution.
>
> My 2 cents,
>
> Tyler
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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