Subject: Re: [xsl] [Ann] Oxygen XML Editor version 23 release From: "George Bina george@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 24 Nov 2020 05:58:40 -0000 |
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
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 bothB 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 <mailto:mike@xxxxxxxxxxxx> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx <mailto: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/634597> (by email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [Ann] Oxygen XML Editor v, Wendell Piez wapiez@ | Thread | Re: [xsl] [Ann] Oxygen XML Editor v, Eliot Kimber ekimber |
Re: [xsl] [Ann] Oxygen XML Editor v, Damian Morris damian | Date | Re: [xsl] [Ann] Oxygen XML Editor v, Octavian Nadolu octa |
Month |