RE: Application Design

[Manos Batsis <m.batsis@bsnet.gr>]

Apologies for the HTML mail... I'm on my two weeks off and this web
based interface sucks. I wont even say the vendor name.
 
<Paul Tchistopolskii>
[...]
I disagree. I'd say that at the moment, XSLT is the 'only'
existing *scripting*  language for simple server side
processing of XML. 
[...]
</Paul Tchistopolskii>
 
If I where to say my "IMHO" in the place of that statement, I would add
that xslt:
 
1) it's not only serverside
2) it's the best at what it does
 
DOM implementations may enjoy wider support in the industry but DOM and
any API, is just that, an API. XSLT is more specific tool and I am sure
that in while, once XPath/XInclude/etc gain even more acceptance, we
will really start using these cleaner ways to do specific markup tasks
that really deserve their own tool for the job.
 
<Don Park>
> I think that the problem with XSLT is that  XSLT
> is often misleading, pretending to be more
> 'powerful' and 'portable'  than it actually is.
</Don Park>
 
Do you really believe that? You just need an xslt processor and there is
a few of them with great level of standard support, for any platform.
Thats mostly as far as it can go.
 
<Don Park>
3. Learning an API like DOM is far easier to learn a new declarative
language like XSLT.
4. Once you learned DOM, there is no real need to learn XSLT.
 
[...]
 
Even if XSLT become universally available in browsers, JavaScript and
DOM
combination will be the preferred method of implementation.

</Don Park>
 
Not so. I'm not an xslt wizard or something, but I would preffer XSLT
opposed to anything from week #2 most elements are quite easy to learn
and used;  as long as you keep your code right and simple you don't
really need anything else. I'm working on a project that would take at
least twice the development time in any language, plus it would really
get rather complicated and difficult to maintain. Aslo, XSLT can work
both client and server side, something that leaves me only one version
of code to edit while pushing much of the server's load to the clients
that can handle it.
 
As my work involves web based interfaces for anything we do, I have
reached the conclusion that siply the two things we compare are for
different functions. DOM is just a plugin for your favorite generalized
language. But when you have to filter data from xml to another document
or application, it's great as it transforms; you have the picking and
the packaging in the same space defining the one to the other in a
direct clean syntax. Yes xslt can get complicated but using JavaScript
instead sounds like what_did_i_typed_30"_ago kind of trouble. 
 
<Al Snell>
Yep, and we're still suffering as a result (Win NT has kinda caught up
with OS/2 in most respects, but still...). Fight now before XML does the
same! :-)
</Al Snell>
 
Nice post. Just wanted to say that if there where a language,  in non
XML syntax, able to do what xslt does in the same level of directivity
then I would probably use it.
 
And of course there is what Soumitra Sengupta points out, xslt lucks
some serious debugging tools, although we have already started seeing
efforts on this. But it's also the compatibility level when compared
with a language/DOM (even with those processor extensions around) that
gives you less work to do instead of dealing with "bugs" caused by
incopatibilities of a general language support among platforms.
Personally, I am rather dissapointed by the work on DOM compatibility
between implementations, "they" still preffer making extensions instead
of implementing the standard to a higher degree.
 
Kindest regards,
Manos