1. Customary License Categories
2. Pricing Table
3. License Examples
4. Source Code License

Customary License Categories

Except for the entry-level standalone-system license (Spot Use below), the pricing scheme entitles to equip any number of CPU's, computer systems and users under the same single license. The pricing scheme tries to match the uses' worth, hence the context or scope (Application, Site, Enterprise) of use, which can be roughly measured by the number of different base namespace URIs that will characterise the generated XML documents.

The license categories are defined as follows:

Non-automated Context

Message or data transformations are triggered by a script or program directly or indirectly invoked by a human person who monitors the outcome.
No price is listed further for such Non-automated Context given that it matches the scope of use of the free software version.

Spot Use

The Software is used to solve a precise data transformation issue as part of a specific IT project. The schema namespaces of all generated XML documents (output side) share only one common namespace-URI (Uniform Resource Identifier) prefix, elsewhere denoted as base namespace.

Extended Use

The Software is used in a few IT projects for transforming data in a few business application contexts. The diverse XML document schemas at stake share a very limited number of base namespaces. These base namespaces cover the different URI (Uniform Resource Identifier) prefixes of the namespaces in use in target XML schemas.

Site Use

A Site is one office location or address. The Software Products are used to transform data for potentially all business applications at this Site. The number of base namespaces that can be activated for use in output XML documents is unlimited.

Enterprise Use

An Enterprise is defined by all Sites of the same legal entity. Just like XSLT, reverseXSL software becomes a standard component in possibly every IT project in the Enterprise. The number of base namespaces that can be activated is unlimited.

A Third Party Service Provider

SaaS, ASPs, BSPs, and in general value added service providers which would execute the Transformer to the benefit of third parties shall contact us for specific quotes.

The XML documents generated by the Transformer can be targetted at various namespaces, using the SET BASENAMESPACE statement in message DEFinition files. Companies typically use only a few of those in practice for the XML documents that they produce (reminding that we count here the base or root namespaces, and only on the output side: e.g. a domain URI like 'http://www.myCompany.com'. It can be extended with any suffix like '/trade/xml/ordering/v1' to yield a distinguished XML message namespace like 'http://www.myCompany.com/trade/xml/ordering/v1' ).

Each base namespace to be used in generated XML documents requires activation within the software . You don't need to have a list ready before purchase as you can activate them anytime later, as the need arises. Moreover, you can upgrade a license at any time to the one above for 120% of the difference in price.

The different license categories are formally described within the License Agreement itself. In case of ambiguity between the definitions in the formal license agreement, the interpretation most favourable to the user applies.

Pricing Table

It is important to remember that a single license allows executing the Transformer software on any number of computers servicing and supporting the same licensed context; for instance, one production system, plus one failover system, plus one test server and one development server, plus the three developers' workstations. That does make the price a bargain if you ever compare it to alternative solutions.

The column #URIs indicates the number of base namespace URIs included in the license category (as explained in the previous section). You can always upgrade later on, for the difference in price, augmented by 20%.

REMINDER: one-off price for any number of computers from development to production supporting the application context(s) in scope.

Examples

Spot Use

• A software developer executes the reverseXSL software on his workstation to prepare XML test messages from a legacy data source, as part of an application migration project.
• An office user in a Company has developed an MS-Excel spreadsheet that consolidates financial exposure risks. His data is integrated into a web page that is published on the Intranet every day. The reverseXSL software is used to prepare diverse page fragments in XML before translation to XHTML with XSLT.

Site Use

• A medium-size company with remote commercial agencies but all its manufacturing facilities and busines applications at a single office location operates an EDI/EAI platform already equipped with a data mapping engine. A few applications generate screwy formats that pose parsing difficulties for the flat-file processor embedded in adapters / application connectors. The reverseXSL software provides a much cheaper and faster solution copmpared with the custom development of application interface wrappers, or ad-hoc file processing modules based on the adapter development kit.
• All commercial representatives of a Company connect to an extranet every day and launch via an applet on a portal a set of data synchronisation jobs between their PC and a central application. The reverseXSL software is integrated in the applet, extending its raw data import/export capabilities.

Enterprise Use

• A large company operates several integration platforms—historically—servicing numerous IT projects that have to progress in parallel at any point in time. The idea of consolidating all integration resources into a unique competency center failed as it revealed itself a costly bottleneck and important source of delay (plus coordination overheads) to all application project teams. On the other hand, standardisation initiatives were more successful and a common queuing infrastructure conveying XML data is in generalising use. Just like the XSL Transformer being used elsewhere at different places by different teams in several project frameworks, the reverseXSL Transformer becomes a component of the software libraries made available to all developers to accelerate their projects.
• A company has successfully grown a data exchange infrastructure; countless file transfers and data processing operations are triggered every day by a job scheduler. Newest applications talk exclusively in XML, and service-oriented interactions progressively replace batches of proprietary data exchanges. XSL combined with reverseXSL software provide convenient means to quickly engineer reliable ad hoc interfaces with legacy applications (and trading partners) talking in proprietary formats, following the progress of application migrations.
• An airline re-engineers one of its mainstream flight operation applications, using XML technologies indeed. However, this application requires a connection to the SITA network, over which data exchanges are based on the non-XML IATA standards. The former application was developed for those standards—mapping was not an issue. Acquiring a new EAI/EDI platform just for the sake of serving as a gateway is altogether very costly, very heavy in operational terms, heavy in specific learning requirements, and seldom convincing in term of truly handling the screwy airline messaging standards; else, with promises for extensive customizing. In such a context, the use of reverseXSL and XSLT is an easy decision for the savings in investment (acquire the technology and develop the mappings), time (set-up and develop), and recurring cost (operational footprint = only one jar plus DEF and XSL files on the classpath!).