[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Application Design
- From: Manos Batsis <email@example.com>
- To: Paul Tchistopolskii <firstname.lastname@example.org>, email@example.com
- Date: Mon, 13 Aug 2001 07:23:06 +0300
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.
I disagree. I'd say that at the moment, XSLT is the 'only'
existing *scripting* language for simple server side
processing of XML.
If I where to say my "IMHO" in the place of that statement, I would add
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.
> I think that the problem with XSLT is that XSLT
> is often misleading, pretending to be more
> 'powerful' and 'portable' than it actually is.
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.
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.
combination will be the preferred method of implementation.
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
instead sounds like what_did_i_typed_30"_ago kind of trouble.
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
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.