| Newsgroups |
gmane.text.xml.xsl.general.mulberrytech |
| Message-ID |
<[email protected]> |
Hi all,
Thank you all for your feedback, it is really helpful!
I want to clarify some things from the oXygen perspective:
* We never considered removing XSLT 1.0 support in oXygen.
* We did not remove any processors, we just marked some very old ones as
"deprecated".
This will increase the chances of new oXygen and XSLT users to choose a
newer engine when they try XSLT for the first time.
It will help also our support - if an issue is found in a processor that
we include in oXygen, in many situations we did more than just to report
the issue to the original project, we investigate it to understand the
problem, try to fix it and send patches, and sometimes apply patches on
our side. Marking something as "deprecated" allows us to avoid
supporting these engines at this level, because it sets correctly the
expectation for our users.
We surely do not want to remove processors that our users still use and
need, but we do not have many ways available to get this information.
Marking something deprecated helps people to react and let us know that
they are still using those processors - what just happened here :).
Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
On 11/23/20 11:57 PM, Wendell Piez [email protected] 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 [email protected]
> <mailto:[email protected]> <[email protected]
> <mailto:[email protected]>> 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 <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/3329386
or by email: [email protected]
--~--