[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [Ann] Oxygen XML Editor version 23 release
As an aside re IBM System 360 in today's world: I learned the other day that a friend has taken a new job building a system that generates modern Web applications that replace existing System 360 applications, even going so far as to emulate to some degree the look and feel of old 3270 display UIs. He said this was mostly for U.S. Federal agencies, which does not surprise me (now that I work for one). As I was leaving IBM in 1993 the writing group I worked with was exploring using those same "360-on-a-card" boards to move our document processing from expensive mainframes (over a $1 million a year in compute time to format our books) onto PS/2s. I remember seeing a little tower machine with this arm-thick cable going into it from a big hard drive. One of my recent contracts still has an SGML-based home-grown CMS from 20 years ago that requires that they find emulators to run the ancient version of Linux it was built on--they can't replace it because it would more expensive than they can afford to reproduce all the features that have accumulated over the last 20 years, as much as they would like to. It was a painful situation to witness but the money simply wasn't there to do the replacement as long as the system still works. Cheers, E. -- Eliot Kimber http://contrext.com o;?On 11/23/20, 3:57 PM, "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: Hi, I agree with all the disagreements so far. To return to the beginning of the thread, it seems fair to say that there is a reasonable use case for oXygen in continuing to maintain XSLT 1.0 support alongside with XSLT 2.0, for the sake both of crusty old systems and their maintainers who do not wish to be pushed into Visual Studio, and perhaps for easing their migration pathway into industrial-grade XSLT in future. Indeed it seems to me oXygen already has almost everything you would need to set up the regression testing that Mike reminds us is incredibly useful if not indispensable for sane sensible system maintenance or migration - and having set up your testing for 1.0 you can test your 3.0 system alongside it, like Liam's French power company. Maybe put them into a git repo so your parallel power systems live safely in the cloud. To add a story to one of Norm's remarks, it must have been almost 40 years ago that my uncle, who designed APIs for IBM at the time, once showed me an XT box sitting open on a bed, its guts exposed. He pointed to a sizable PCI board plugged into the chassis and asked me what I thought it was. To my blank look, he said "IBM 360". I don't know if they still use boards or chips today (this was in the era of the XT): maybe it's all emulators? This also goes to Norm's point of course. Some kinds of technology get baked in to the point where their support in effect becomes indefinite. However, the IBM 360 was IBM IP (wasn't it?) and who knows where the emulators stand. (Lawyers.) With no built-in revenue model around XSLT itself, it's more difficult for an XSLT industry to sustain itself. (Mike's point.) However, without free and open alternatives to proprietary stacks and lock-in, no open technology stands a chance, however "standard". For example, it might be doubted whether there would be even the demand there is today for XSLT 3.0, had we not all along had a healthy commodity ecosystem implementing the 1.0 generation and giving us success stories to build on. With its rather free-form type system, XSLT/XPath 1.0 is also in my view conceptually lightweight compared to 2.0+, which gives it certain kinds of advantages for certain purposes. It may shock you, but I have even heard XSLT developers refer to "good old 1.0". Without irony! or anyway that kind. Cheers, Wendell On Mon, Nov 23, 2020 at 2:44 PM Michael Kay mike@xxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: AND, there are things tool vendors can to do make updating easier. For example, providing guidance on how to "fix" things that "break" in such an upgrade. I've recently been trying to help a Saxon user who's managed to get about 10 major releases behind, and it isn't pretty. Most of the things we do to ease upgrade, like keeping things deprecated for a release or two before they are withdrawn, don't work in that situation. Their worst problem though is that they don't have a decent set of regression tests so they just don't know whether their upgrade has been successful or not. That plus the fact that if you close your eyes for ten years and then open them up again, the world is a different place and you're completely disoriented. I'm afraid the more people get out of the habit of paying real money for the software they use, the less the amount of investment that goes into such luxuries. Even when users are paying, $500 doesn't buy you much support. It's sad how very little of the value that the user community has got from good XSLT processors has been fed back to the developers to produce better XSLT processors. Michael Kay Saxonica XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/174322> (by email <>) -- ...Wendell Piez... ...wendell -at- nist -dot- gov... ...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org... ...github.com/wendellpiez. <http://github.com/wendellpiez.>.. ...gitlab.coko.foundation/wendell... XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/1278982> (by email <>)
|
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
|