Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A would-be user's first XSL experience (long)
 Do you know whether Indelv's browser matches the latest specification? Claims support for the 16 Dec 98 draft. Anyhow, I think that for someone learning the details of the XSL specificaiton a batch, command-oriented process is really best. You are doing an XML->XML transform first and an XML->display format second. You should learn and understand one before moving on to the other. Converting to HTML and viewing the HTML *in a text editor* is the best way to get started. I certainly agree. And I'm hearing from you that I must compile and use a command line program to "get started" with this language designed (among other things) to appeal to non-programmers. Is my point so obscure? I can't believe that this is really so hard with Code Warrior. On a PC you open up your text editor and there is usually a menu item called "run command line" You type in a command line and it just works. I mean you've got to be willing to go halfway with us. Sure. Just be aware that for every potential user who is comfortable with compiling and using console apps, there are easily dozens - if not hundreds or thousands - of civilians who aren't. With XSL under attack as difficult - by programmers no less - this appears to me to be a major liability. > Somebody slap an HTML form UI on XP/XT and whatever else is necessary > to make XSL work. Why is it any different from using a Web form to access an SP-driven validator, like the W3C's or WDG's services? Very popular, by the way. Non-casual users who determine the service to be valuable this way can (and do) proceed to install similar locally, with the help of a resident sysadmin type (or purchase commercial GUI software with equivalent functionality). I'm not talking about encouraging this as a production vehicle, but as a learning tool, a free sample, a test drive. It's good marketing. People who have a "successful" experience with the toy front end will be motivated to dust off their programmer hats (or find a programmer) to integrate the stuff into their production environments for real work. I hate to invoke stereotypes of Mac users but you seem to be begging for it. It seems you'd rather waste an hour a day cutting and pasting instead of a single hour figuring out how to use the tools at your disposal. I've spent more than a few hours. I am not a programmer. But forget about me for a moment - I'll keep dutifully banging my head on the wall until I like it (or more likely, until I am pulled away by something else, and drop XSL for a few more weeks or months). Would you prefer that everybody who's less comfortable than I am with programmer's tools uses IE5 as a "reference" GUI for (MS)XSL? That's what will happen if more zealously conformant software is not made equally accessible. > At a minimum, let users provide the URLs of XML > documents linked to XSL stylesheets (or provide the PI manually), and > return the result, whether XHTML, FOs, or some other flavor of XML. Since it's not likely to be of much use as a production tool, I wouldn't be concerned about system resources - shut it off if so. I'd volunteer Verso, but I think it might be better if a party more committed to XSL could take it on, as it would likely be kept most up-to-date and well-annotated/linked that way. I'll bet that the XML.com folk could be persuaded to add such as a complement to their simple "RUWF" toy: http://www.xml.com/xml/pub/tools/ruwf/check.html . I suppose you don't agree that that was worth the development effort either? XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 
|
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
|
