Subject: Re: [xsl] [Ann] Oxygen XML Editor version 23 release From: "Wegmann, Frank frank.wegmann@xxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 23 Nov 2020 16:53:55 -0000 |
Thank you for sharing this. Rethinking current systems and procedures should happen on a continuous basis. At some point in time then it could be appropriate to ensure that revenues are coming in using a modernized system, and maybe even in a more efficient and more maintainable way. Undoubtedly, XSLT 2+ can make things easier (just thinking of grouping techniques and dynamically calling templates). Referring to the original question of Octavian, I have to chime in with others here. Unfortunately, there are vendors of Windows-based software relying on .NET and can only offer, what Microsoft has to offer in .NET Core. And that is XSLT 1.0. I donbt know the .NET business good enough to know whether there are real alternatives for vendors. As long as a key player refuses to modernize his own offering (and their revenues definitely do not depend on having support for XSLT 2 in Redmond), other should keep up their XSLT 1 support for the time being. Especially oXygen... Frank -----Original Message----- From: B Tommie Usdin btusdin@xxxxxxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Sent: Monday, November 23, 2020 17:30 To: xsl-list <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Cc: Tommie Usdin <btusdin@xxxxxxxxxxxxxxxx> Subject: Re: [xsl] [Ann] Oxygen XML Editor version 23 release I don't see what is unfortunate about people using XSLT 1.0. I don't see why people dislike the fact that others are using it. It may be more fun to write in newer versions of the language. There are certainly useful capabilities in XSLTs 2 and 3, and for new applications that need those capabilities it is wonderful that they are available. The implication that users SHOULD rewrite existing, working, code whenever there is a newer better way that it could have been written had it been done years later is ABSURD. XML was successful BECAUSE it worked in existing systems. XML is a bit warty because it was written to make it backward compatible with SGML, so that it would work in existing systems and thus could be relatively rapidly adopted. The use case for XML almost always includes longevity and application independence. We, the XML community, exist because we are able and willing to accommodate our history. I once heard a wonderful story about a presentation made by an IT department to the production department of a publisher. It was all about the new system they were developing and how wonderful it would be. And, in order to free the needed resources to develop the new system, they were going to freeze the legacy system. No new requests for capabilities or even bug fixes would be accepted for the legacy system; they were focussing on the future. After the presentation, the CEO of the organization asked them to give that presentation again, except instead of calling it the "legacy system" they should talk about it as the "revenue system". Now, how many of you think it is acceptable to freeze the revenue system? It seems to me that if you want to stop maintaining parts of your user's Revenue Systems, you should be very careful to give them good instructions on how to move to tools YOU prefer, and remember that you may be imposing significant risks and costs on your customers. -- Tommie > On Nov 23, 2020, at 10:43 AM, Willem Van Lishout willemvanlishout@xxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > I have to agree with the others. XSLT 1.0 is unfortunately still very > prevalent, and I sometimes need to use MSXML to see what quirks it > produces. (There's quite a few of them!) > > If you are really keen on removing them, I would at least consider making them available as easily installable plugins. > > By the way, Geert, I don't think MSXML supports debugging, at least in my Oxygen version it switches to Saxon when I try that. > On Nov 23, 2020, at 15:26, "Geert Bormans geert@xxxxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi Octavian, > > Thanks for the update > > As much as I don't like it... > some customers can not or don't want to migrate to an XSLT version > higher than 1.0, and I am not always in a position to change that (and > that will continue to be so for a long while I am afraid) So I guess I > will be needing debugging support for at least Xalan and msxml 4.0 or > .net for some time to come, it is what it is :-( > > configuring them as external processors, does not give me real > debugging support, does it > > Met vriendelijke groeten, > Best regards, > > Geert Bormans > > ----- Op 23 nov 2020 om 14:47 schreef Octavian Nadolu octavian_nadolu@xxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>: > > Hello, > > Thanks for your feedback. > > We intend to update the Saxon 9 and 10 plugins for the Oxygen XML Editor 23.0. Because this are provided separately as plugins, we can updated them also after the release. > > We decided to deprecate some of the XSLT processors (Xalan, MSXML 4.0, MSXML .NET, .NET 1.0, .NET 2.0 ...) because we do not want to maintain them in the future. We are not sure if we will remove them completely or just mark them as deprecated. But we will maintain the XSLT 1.0 support in Oxygen. Also, you can configure them as external processors. > How many of you are using this processors? > > Best Regards, > Octavian > > On 23.11.2020 10:46, Mukul Gandhi gandhi.mukul@xxxxxxxxx wrote: > On Sun, Nov 22, 2020 at 12:44 PM Mukul Gandhi gandhi.mukul@xxxxxxxxx < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > I can see that, at the preferences oXygen page, XSLT 1.0 dropdown shows Xalan as deprecated. It seems to me that, in a future oXygen version, when Xalan would be removed from the standard oXygen XSLT 1.0 options, one could still use Xalan with oXygen by specifying it on the 'Custom Engines' option. > > Apologies, that I forgot to mention that, I tried oXygen XML Editor version 23. > > > > -- > Regards, > Mukul Gandhi > XSL-List info and archive > EasyUnsubscribe ( by email) > > > -- > Octavian Nadolu > <oXygen/> XML Editor > > http://www.oxygenxml.com > XSL-List info and archive > EasyUnsubscribe ( by email) > > XSL-List info and archive > EasyUnsubscribe ( by email) > XSL-List info and archive > EasyUnsubscribe (by email) ====================================================================== B. Tommie Usdin mailto:btusdin@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. https://www.mulberrytech.com 17 West Jefferson Street Phone: 301/315-9631 Suite 207 Direct Line: 301/315-9634 Rockville, MD 20850 Fax: 301/315-8285 ----------------------------------------------------------------------------- --------------------------------------------- Mulberry Technologies: A Consultancy Specializing in XML for Prose Documents ====================================================================== Software AG b Sitz/Registered office: UhlandstraCe 12, 64297 Darmstadt, Germany b Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Sanjay Brahmawar (Vorsitzender/Chairman), Dr. Elke Frank, Dr. Matthias Heiden, John Schweitzer, Dr. Stefan Sigg - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Karl-Heinz Streibich - http://www.softwareag.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [Ann] Oxygen XML Editor v, B Tommie Usdin btusd | Thread | Re: [xsl] [Ann] Oxygen XML Editor v, Michael Kay mike@xxx |
Re: [xsl] [Ann] Oxygen XML Editor v, B Tommie Usdin btusd | Date | Re: MORE Re: [xsl] [Ann] Oxygen XML, Graydon graydon@xxxx |
Month |