US 20060048112 A1
Enhanced compiled representation of transformation formats to enable rapid application development and deployment is described. Techniques for partitioning data in a transformation include populating a table with a functoid associated with a functoid tree root, traversing the table and generating a page object corresponding to a page number found in the functoid, and instantiating the functoid in the page objects. A system for partitioning data in a transformation is also described, including a memory configured to store a table with a functoid associated with a functoid tree root, and a processor configured to traverse the table and generate a page object corresponding to a page number found in the functoid, and instantiate the functoid in the page object corresponding to the page number.
1. A method for partitioning data in a transformation, comprising:
populating a table with a functoid associated with a functoid tree root;
traversing the table while marking the functoid with a page number and generating a page object corresponding to the page number associated with the functoid; and
instantiating the functoid in the page object, wherein the page object corresponds to the page number.
2. A method as recited in
3. A method as recited in
4. A method as recited in
5. A method as recited in
6. A method as recited in
7. A method as recited in
8. A method as recited in
9. A method as recited in
10. A method as recited in
11. A system for partitioning data in a transformation, comprising:
a memory configured to store a table with a functoid associated with a functoid tree root; and
a processor configured to traverse the table while marking the functoid with a page number and generating a page object corresponding to the page number associated with the functoid, and instantiating the functoid in a page object, wherein the page object corresponds to the page number.
12. A system for partitioning data in a transformation, comprising:
a compiler configured to populate a table with a functoid associated with a functoid tree root;
a builder configured to traverse the table while marking the functoid with a page number, generating the object model using the object tree; and
a rendering engine configured to instantiate a target instance using the object model to generate an application-specific object model.
13. A computer program product for partitioning data in a transformation, the computer program product being embodied in a computer readable medium and comprising computer instructions for:
receiving a transformation specification;
generating an object model using a schema; and
converting the transformation specification into an application-specific transformation the object model.
14. A computer program product for partitioning data in a transformation, the computer program product being embodied in a computer readable medium and comprising computer instructions for:
populating a table with a functoid associated with a functoid tree root;
traversing the table while marking the functoid with a page number;
generating a page object corresponding to the page number in the functoid; and
instantiating the functoid in the page object.
This application is a continuation of U.S. application Ser. No. 10/934,247, filed on Sep. 2, 2004, which is hereby incorporated by reference in its entirety for all purposes as if fully set forth herein.
The present invention relates generally to software. More specifically, enhanced compiled representation of transformation formats.
Developing and deploying enterprise software applications for various purposes may be problematic in terms of integration and scalability. In order to implement applications from multiple vendors, integration and architectural issues arise, such as whether to use a single or multiple sources of data to support the disparate applications. Industry standards recommendations such as those endorsed by the World Wide Web Consortium (W3C) were developed for the purpose of addressing these types of issues. By using a standard data format (e.g., XML), software developers, designers, architects, and programmers (hereinafter “developers”) can develop numerous, disparate applications for varying purposes. However, common data formats such as XML still pose significant difficulties between applications.
Using XML-formatted data enables applications to present content without the static limitations of HTML. The capability for using a single source of data (e.g., XML-formatted data) with various applications is an attractive feature of XML. By using XML-formatted data, various applications can be tailored to work with a common dataset for purposes such as accounting, supply chain management, financial/currency conversion, operations management, and others. However, XML-formatted data retrieved for use with one application must be transformed before use with other applications. Transformations between applications requires substantial time, effort, and skill to transform XML-formatted data. Another W3C recommendation, Extensible Stylesheet Language (XSLT) provides standards for performing transformations on XML-formatted. Different applications often require XML documents to be transformed from one XML version to another and, generally, XSLT may be used as a common set of techniques for transformation. However, conventional techniques for performing transformations are also problematic.
Conventional techniques for performing data transformations are typically performed manually. Performing manual transformations does not scale well for applications. Transformations are dependent upon the skills of a developer and may be error-prone. Importing transformations or documents into a specific application requires using specifications from XSLT and XSD files (e.g., files used to generate source code for run-time objects that correspond to an XML schema). Although industry standards recommendations such as XML and XSLT exist, these and other conventional techniques are also problematic when used to migrate data between applications. For example, data from a legacy accounting application may require substantial transformation before being used in a more recent financial application developed by another vendor.
Thus, what is needed is a solution for performing transformations without the limitations of conventional techniques.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings:
The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
Transformations of documents, document objects, formatted data, and other types of information may be implemented to enable efficient operation of disparate integrated applications and systems. As used herein, applications may refer to computer programs, software, software systems, and software-implemented systems that are suitable for a variety of purposes. Using standards such as XML, XSLT, XPath, and others, the design, deployment, and implementation of integrated applications may be improved by eliminating manual transformations. Further, transformations may be imported into application-specific artifacts or abstractions to facilitate data migration between systems, depending upon application-specific requirements.
In system 100, transformation system 102 and application system 104 act as a tool for importing XSLT transformations using HTOM 116. Application-specific constructs, objects, documents, document objects, artifacts, or other data formats may be transformed. As an example, HTOM 116 provides a generic intermediate base for transforming XSLT transformations for use with specific applications. In other examples, HTOM 116 may be used to transform other data formats other than those described above. Transformation system 102 transforms objects such as XSLT transformation document 106 using various components.
Transformation system 102 develops HTOM 116, which is used to transform data from one format (e.g., XSLT transformation) to another (e.g., XML) for use by various applications. As an example, XSLT transformation document 106 is used by XSLT compiler 108 to create HTOM 116, which is used by application system 104 to generate an application specific object model 128. Components of transformation system 102 and application system 104 enable the manipulation and execution of XSLT transformation document 106.
As an example, XSLT transformation document 106 acts as an input to transformation system 102. Transformation system 102 receives XSLT transformation document 106 and creates HTOM 116, using XSLT compiler 108. Source and target context builder 110, XPath compiler 112, and optimizer 114 may be used by XSLT compiler 108 to generate HTOM 116.
Source and target context builder 110 instantiates a source and target schema on-the-fly and establishes a pointer to an appropriate node in the instantiated schema, for example. Source and target context builder 110 also analyzes XPath expressions and extracts node and axis information. In some examples, source and target context builder 110 may ignore some constructs. Source and target context builder 110 traverses a node and axis determined from the source schema to determine the position of a node referenced in a path specified by the XPath expression being analyzed. If source and target context builder 110 is unable to determine a node, parent and child nodes may be generated along a path in the target object tree for HTOM 116. The children and parent nodes may be referred to as context nodes for XSLT compiler 108. Context nodes are part of a context that is used to evaluate an expression to generate an object. In this example, the evaluation of nodes enables an object tree related to HTOM 116 to be constructed, which may be used to generate application-specific object model 128 and, eventually, application-specific transformation document 132. Here, context may describe a position, size, set of variable bindings, function library, and a set of name space declarations for a given expression. In other examples, context may describe other parameters.
In this example, context nodes generate absolute paths to a node within a source XML document referenced by an XPath expression embedded inside an XSLT construct (e.g., XSLT transformation document 106). XSLT transformation document 106 may be used to point to a particular node or instantiate a particular node in a target tree for a target XML document using HTOM 116. This technique for generating an XML instance to transform a source XML document into a target XML document by analyzing an XPath expression allows the generation of a fragment of an original schema. The fragment of the original schema may be referenced by XSLT transformation document 106.
By generating schema fragments, contextual information may be managed to reduce a memory footprint associated with HTOM 116 and the target schema. A fragment of an original schema tree may be used to generate HTOM 116, application-specific object model 128 and transformation document 132, instead of using an entire source tree from a source XML document, thus reducing memory requirements. XSLT compiler 108 creates HTOM 116 using fragments, which may be parsed from an original source schema tree associated with XSLT transformation document 106.
XSLT compiler 108 parses input XSLT transformation document 106 using, in some examples, a depth-first search algorithm. nodes may be mapped from the object tree to HTOM 116 using an object tree associated with XSLT transformation document 106. XSLT compiler 108 may include a custom handler (not shown) for each XSLT construct received. Some examples of XSLT constructs include xsl:for-each, xsl:if, xsl:choose, and others. In some cases, XSLT constructs such as xsl:for-each may change a source schema context associated with XSLT transformation document 106, while a target element sets up a target schema context in HTOM 116. Constructs may also use a source and target schema context to derive links to source and target schema elements. Expressions (e.g., XPath expressions) contained within XSLT transformation document 106 may provide constructs and source schema elements. Various components of transformation system 102 may be used to derive and render target schema elements in HTOM 116.
As an example, XSLT compiler 108 compiles XSLT transformation document 106 using services provided by source and target context builder 110, XPath compiler 112, and optimizer 114 to create HTOM 116. XSLT compiler 108 may also use services provided by source and target context builder 110 to maintain a source-to-target schema and context during parsing. Each XSLT construct may be used by XSLT compiler 108 to create objects (e.g., XslItemContainer, XslItem, and others) in HTOM 116. An XSLT construct may also have associated XPath expressions to indicate the location of various objects, destination nodes, or other information used to construct HTOM 116. For example, when XSLT compiler 108 encounters an XPath expression, XPath compiler 112 may be invoked to compile the expression. XSLT compiler 108 receives output from XPath compiler 112 and attaches it to an associated object in HTOM 116. XSLT compiler 108 also stamps each object (e.g., xslItem, xslItemContainer, and others) with a unique identifier and also marks up the original XSLT transformation document 106 with the same identifier by adding an attribute to the XSLT node on the object tree associated with the source schema. These unique identifiers correlate compiled HTOM tree fragments with tree fragments in XSLT transformation document 106 and may be used to render tree relationships visually using HTOM viewer 122. XSLT compiler 108 also calls optimizer 114 to optimize generated HTOM 116.
XPath compiler 112 tokenizes an XPath expression into various types of tokens representing axes, functions, constants, and other parameters. XPath compiler 112 also maps each token to an object representation and constructs a parse tree of the objects. The parse tree structure is then returned to XSLT compiler 108, which then attaches it to HTOM 116.
Optimizer 114 traverses the tree structure associated with HTOM 116 in depth-first fashion and eliminates redundant objects. Pattern detection mechanism 115 identifies redundant fragments of HTOM 116 that may be compressed. For example, if an “AND” operator object is connected to another “AND” operator object, then pattern detection mechanism 115 combines the redundant operator objects into a single “AND” operator object. In another example, if two tree fragments are identical, then one of the redundant fragments may be eliminated.
HTOM 116, in this example, is an object model that represents both XSLT objects and XPath expressions in a hierarchical structure. XSLT objects may include XslItemContainer and XslItem. In some examples, XslItem is a type of atomic XSLT construct that represents leaf-levels in the tree-structure of XSLT documents. Examples of XslItem include xsl:value-of and xsl:copy-of. XslItemContainers may be used as containers for other XslItemContainers or XslItems. Examples of XslItemContainers include xsl-for-each, xsl-if, xsl-choose, and others. Examples of both XSLT objects and HTOM 116 are described in greater detail below in connection with
Application system 104 may have various requirements, components, and architecture for rendering HTOM 116. HTOM 116 enables the generation of a specific model that may be used for execution, visualization or other representations for a specific application. In this example, application system 104 receives HTOM 116 at transformation rendering engine 124. Transformation rendering engine 124 uses services of post processor 126 to create application-specific object model 128, which may be serialized to create a file representation that is specific to a particular application. In some examples, a file representation enables manipulation and execution of XSLT transformation document 106 inside an application environment such as application system 104. XSLT transformation document 106 may be used in many application development and integration scenarios.
Application system 104 includes several components including transformation rendering engine 124, post processor 126, application-specific object model 128, object model serializer 130, and transformation document 132. Transformation rendering engine 124 traverses a tree associated with HTOM 116 and transforms XPath expression objects into application-specific objects such as functoids and links. As an example, a functoid is an abstract representation that combines the definition of the functionality and information about the representation in a host environment. In some examples, XPath expression objects may have a one-to-one correspondence with application-specific functoids, while others are mapped to a combination of different functoids. In other examples, XSLT constructs may be handled using specific types of functoids based on application-specific requirements. As an example, transformation rendering engine 124 may replace an HTOM tree fragment with a functoid of type “Inline XSLT Scripting Functoid.” Transformation rendering engine 124 may also analyze the containment hierarchy of XslItemContainer objects and create AND or value mapping functoid objects to represent nested conditions.
Transformation rendering engine 124 may also “plug-in” custom functoid implementations based on the configuration of an XML document, object, or file, in some examples. Custom functoids may be implemented and derived from an application-provided base class. Custom functoids may also be created as a public method in frameworks such ‘.NET’ assembly. Depending on a particular implementation, functoids may be represented as different objects in application-specific object model 128. Implementation may be determined by using a configurable XML file that captures information from custom functoids such as namespace, implementing assembly, and either a functoid ID or a function name. In some examples, functoids may not be able to act as input to other functoids, using re-ordering in an object tree associated with application-specific object model 128 to compensate.
Post processor 126 analyzes an application-specific object tree to detect patterns that may not be allowed by transformation rendering engine 124 and re-organizes the object tree to resolve application-specific object model 128. Post processor 126 may be implemented using a “pattern detection XML” file to capture information related to transformation rendering engine 124. Post processor 126 may apply pattern matching and fixing algorithms to re-arrange an object tree associated with application-specific object model 128, which is discussed in greater detail below in connection with
Object model serializer 130 serializes application-specific specific object model 128 into a memory file (e.g., .btm file). A memory file primarily contains XML nodes with tags such as functoids and links. Memory files may also contain meta-data about a transformation such as source schema, target schema, grid, and other parameters. Object model serializer 130 traverses an object tree, formats absolute paths for source and target schemas using a source and target context, and generates associated functoid and link nodes. Object model serializer 130 also generates the correct syntax for functoid nodes depending on the type of functoids. Object model serializer 130 also creates new “page” nodes when an unserialized object is encountered prior to pagination (i.e., placement on a page). In some examples, object model serializer 130 also generates and associates “external object” files for transformation rendering engine 124 to bind custom functions used in inline XSLT functoids to assemblies that implement inline XSLT functoids.
XslItems 410-412 represent elements that may be used to instantiate content, such as text or a particular value, extracting the content from a source document (e.g., XSLT transformation document 106) to a target document (e.g., transformation document 132. Here, xsl: value-of is used to extract content from a source document using an expression specified in an attribute of the element. Functions 414, 418, 422, 426, and 430 are also shown, along with links to destination nodes 416, 420, 424, 428, and 432.
In one example, functions 414, 418, 422, 426, and 430 may be represented using function tree fragment 500. Here, functions 502-512 receive inputs such as a literal string of text (e.g, ‘ACCT”, ‘CHK’, ‘10000’, ‘GOLD’, or others) or content from a source node of a tree related to a source XML document, such as those inputs provided to function 506 or element 514. Element 514, in this example, retrieves an ID number, which may be extracted from either a literal string, or a source XML node, as described. In other examples, elements and functions may retrieve content from different types of sources. Once received, inputs are used to perform functions such as those shown in functions 504-508. By processing tree schemas using the techniques described above, HTOM 116 may be used to create transformation document 132 and may also be used to provide a visual display of the target-to-source schema, as illustrated in the example of
For example, tree window 602 illustrates XslItemContainers, XslItems, positions, functions (i.e., functoids), node and axis information, and other parameters associated with a tree fragment. Transformation document window 604 illustrates XSLT elements, attributes, and other XSLT constructs that map to the tree fragment shown in tree window 602. Also included in this example is a message window 606 for illustrating results and output messages related to XSLT transformations as a result of, for example, pattern detection mechanism 115. Mismatches, detected patterns, redundant objects, or other event-related messages may be displayed in message window 606. In other examples, fewer or more windows may be implemented. Also, different types of windows may be used to illustrate other information related to XSLT transformations. Examples of pattern specification and detection mechanisms are illustrated below in connection with
According to one embodiment of the invention, computer system 1300 performs specific operations by processor 1304 executing one or more sequences of one or more instructions contained in system memory 1306. Such instructions may be read into system memory 1306 from another computer readable medium, such as static storage device 1308 or disk drive 1310. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention.
The term “computer readable medium” refers to any medium that participates in providing instructions to processor 1304 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as disk drive 1310. Volatile media includes dynamic memory, such as system memory 1306. Transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 1302. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
Common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave, or any other medium from which a computer can read.
In an embodiment of the invention, execution of the sequences of instructions to practice the invention is performed by a single computer system 1300. According to other embodiments of the invention, two or more computer systems 1300 coupled by communication link 1320 (e.g., LAN, PSTN, or wireless network) may perform the sequence of instructions to practice the invention in coordination with one another. Computer system 1300 may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link 1320 and communication interface 1312. Received program code may be executed by processor 1304 as it is received, and/or stored in disk drive 1310, or other non-volatile storage for later execution.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.