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(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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... ...gitlab.coko.foundation/wendell...
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--