Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Application Design
 Apologies for the HTML mail... I'm on my two weeks off and this web based interface [expletive deleted]. 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
