Re: [xsl] [Ann] Oxygen XML Editor version 23 release

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