How to Install and Uninstall saxon10 Package on openSUSE Leap
Last updated: November 07,2024
1. Install "saxon10" package
Please follow the instructions below to install saxon10 on openSUSE Leap
$
sudo zypper refresh
Copied
$
sudo zypper install
saxon10
Copied
2. Uninstall "saxon10" package
Learn how to uninstall saxon10 on openSUSE Leap:
$
sudo zypper remove
saxon10
Copied
3. Information about the saxon10 package on openSUSE Leap
Information for package saxon10:
--------------------------------
Repository : Update repository with updates from SUSE Linux Enterprise 15
Name : saxon10
Version : 10.9-150200.5.3.1
Arch : noarch
Vendor : SUSE LLC
Installed Size : 4.4 MiB
Installed : No
Status : not installed
Source package : saxon10-10.9-150200.5.3.1.src
Upstream URL : https://www.saxonica.com/
Summary : The SAXON XSLT Processor from Michael Kay
Description :
The Saxon package is a collection of tools for processing XML documents. The
main components are:
• An XSLT processor, which can be used from the command line, or invoked from
an application, using a supplied API. Saxon implements the XSLT 3.0
Recommendation. The product can also be used to run XSLT 2.0 stylesheets, or
XSLT 1.0 stylesheets in backwards compatibility mode.
• An XPath processor accessible to applications via a supplied API. This
supports XPath 2.0 and XPath 3.1. It can also be used in
backwards-compatibility mode to evaluate XPath 1.0 expressions.
• An XQuery processor that can be used from the command line, or invoked from
an application by use of a supplied API. This supports XQuery 3.1, which also
allows XQuery 1.0 or 3.0 queries to be executed. With Saxon-EE, you can also
use the XQuery extensions defined in the XQuery Update 1.0 Recommendation, but
later working drafts of XQuery Update are not supported (W3C has abandoned work
on these versions).
• An XML Schema Processor. This supports both XSD 1.0 and XSD 1.1. This can be
used on its own to validate a schema for correctness, or to validate a source
document against the definitions in a schema. It is also used to support the
schema-aware functionality of the XSLT and XQuery processors. Like the other
tools, it can be run from the command line, or invoked from an application.
• On the Java platform, when using XSLT, XPath, XQuery, or XML schema
validation, Saxon offers a choice of APIs. If you need portability across
different vendors' tools, you can use the JAXP API for XSLT, XPath, and XML
Schema processing, and the XQJ interface for XQuery. On the other hand, if you
want a more integrated and complete API offering access to all Saxon's
facilities, the s9api interface is recommended. You can also dive down deeper
into the Saxon internals if you need to: there has been no particular attempt
to make interfaces private, and all public interfaces are documented in the
JavaDoc. Clearly, the deeper you go, the greater the risk of interfaces
changing in future releases.
• On the .NET platform, Saxon offers an API that enables close integration with
other services available from .NET, notably the XML-related classes in the
System.Xml namespace. It isn't possible to use Saxon as a transparent plug-in
replacement for the System.Xml.Xsl processor, because the API for the Microsoft
engine using concrete classes rather than abstract interfaces. However, it is
possible to use it as a functional replacement with minor changes to your
application code.
--------------------------------
Repository : Update repository with updates from SUSE Linux Enterprise 15
Name : saxon10
Version : 10.9-150200.5.3.1
Arch : noarch
Vendor : SUSE LLC
Installed Size : 4.4 MiB
Installed : No
Status : not installed
Source package : saxon10-10.9-150200.5.3.1.src
Upstream URL : https://www.saxonica.com/
Summary : The SAXON XSLT Processor from Michael Kay
Description :
The Saxon package is a collection of tools for processing XML documents. The
main components are:
• An XSLT processor, which can be used from the command line, or invoked from
an application, using a supplied API. Saxon implements the XSLT 3.0
Recommendation. The product can also be used to run XSLT 2.0 stylesheets, or
XSLT 1.0 stylesheets in backwards compatibility mode.
• An XPath processor accessible to applications via a supplied API. This
supports XPath 2.0 and XPath 3.1. It can also be used in
backwards-compatibility mode to evaluate XPath 1.0 expressions.
• An XQuery processor that can be used from the command line, or invoked from
an application by use of a supplied API. This supports XQuery 3.1, which also
allows XQuery 1.0 or 3.0 queries to be executed. With Saxon-EE, you can also
use the XQuery extensions defined in the XQuery Update 1.0 Recommendation, but
later working drafts of XQuery Update are not supported (W3C has abandoned work
on these versions).
• An XML Schema Processor. This supports both XSD 1.0 and XSD 1.1. This can be
used on its own to validate a schema for correctness, or to validate a source
document against the definitions in a schema. It is also used to support the
schema-aware functionality of the XSLT and XQuery processors. Like the other
tools, it can be run from the command line, or invoked from an application.
• On the Java platform, when using XSLT, XPath, XQuery, or XML schema
validation, Saxon offers a choice of APIs. If you need portability across
different vendors' tools, you can use the JAXP API for XSLT, XPath, and XML
Schema processing, and the XQJ interface for XQuery. On the other hand, if you
want a more integrated and complete API offering access to all Saxon's
facilities, the s9api interface is recommended. You can also dive down deeper
into the Saxon internals if you need to: there has been no particular attempt
to make interfaces private, and all public interfaces are documented in the
JavaDoc. Clearly, the deeper you go, the greater the risk of interfaces
changing in future releases.
• On the .NET platform, Saxon offers an API that enables close integration with
other services available from .NET, notably the XML-related classes in the
System.Xml namespace. It isn't possible to use Saxon as a transparent plug-in
replacement for the System.Xml.Xsl processor, because the API for the Microsoft
engine using concrete classes rather than abstract interfaces. However, it is
possible to use it as a functional replacement with minor changes to your
application code.