Browse Prior Art Database

An adaptive approach to exchange XSLT 2.0 runtime data between two execution environments

IP.com Disclosure Number: IPCOM000202317D
Publication Date: 2010-Dec-13
Document File: 3 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

This invention disclosure describes an adaptive solution to exchange XSLT 2.0 runtime data between two different execution environments.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 3

An adaptive approach to exchange XSLT 2.0 runtime data between two execution environments

Disclosed is a process to exchange Extensible Stylesheet Language Transformations (XSLT) 2.0 runtime data between two different execution environments. The two execution environments can reside on different physical machines. In a typical implementation scenario, there are two different Java Virtual Machines (JVM). The XSLT 2.0 runtime data are retrieved from one JVM (referred to as the engine side), encoded into a string format and sent across the network to another JVM (referred to as the client side). On the client machine, the original XSLT runtime data are restored by decoding the string values. The disclosed process fulfills two requirements of integrity and efficiency. Integrity means that the information sent across the wire is enough to restore the original data. Fulfilling the efficiency requirement means the disclosed process minimizes the communication cost and only sends a minimal amount of information at the beginning. Additional information should be retrieved on-demand when needed.

The exchanged XSLT 2.0 runtime data are XPath 2.0 entities. Each piece of data represents an XPath 2.0 value, which can be a singleton item or a sequence. A singleton item can be either an atomic value or a node. An XPath 2.0 atomic value has an associated type. The type can be one of the built-in XPath 2.0 schema types or a user-defined type defined in a schema file. The type of a node value can be either one of the built-in node types (for example, element, attribute, text, etc.) or a type defined in a schema file. A sequence can be viewed as an array that contains a mix of atomic values and nodes.

The disclosed process encodes enough information about the runtime data to enable restoring the same information on the client side. The disclosed process uses different ways to encode and decode different types of data so the data can be fully restored on the client side. The information encoded into the string always includes a type identifier and the string value of the runtime data. A set of unique integer identifiers is used to represent built-in atomic types and built-in node types. When the type is a user-defined schema type, the real type name is encoded into the type identifier. For a node value, additional information such as the source location of a node is encoded.

When encoding atomic values a set of predefined integers is introduced to represent the built-in XPath 2.0 schema types1. When the type of a value is a user-defined schema type, then the qualified type name is encoded into the string. The following examples show how atomic values are encoded.

Example 1: An atomic value with type

xs:integer

            is 5, this atomic value is encoded as "5,10" by concatenating the type identifier with the string value.

Example 2: An atomic value whose type is dx:bigInt and value is 5000. The type dx:bigInt is a user defined schema type derived from

xs:inte...