CONTENT MANAGEMENT SYSTEM

A method may include receiving an input at design time specifying an application to support and receiving an input describing an application user scenario to support. The method may also include determining all possible semantic components required to support the application user scenario and determining all possible properties for the semantic components. The method may also include determining all possible operations in the application necessary to achieve the application user scenario. The method may also include mapping each operation to the semantic components and each property for the semantic components.

DESCRIPTION OF EMBODIMENTS

The present disclosure relates to a content management system configured to receive a first content and provide semantically equivalent second content among same or different formats.

For example, in some implementations two users are editing a document together. A first user uses a first application to edit the document and a second user uses a second application to edit the same document. A first client device of the first user also includes a first content module such as the one described below inFIGS. 2-5Band7-14. A second client device of the second user may also include a second content module. The first application may be a first word processor and the second application may be a second word processor. The first application has a format that is different from the second application.

The first user opens the document using the first application. The document has an associated operations list. The operations list includes a description of all the operations present in the document. The user provides inputs to the first application to edit the document. For example, the user adds a paragraph or moves some text.

As the user edits the document, the content module determines a combined operations list. The combined operations list includes a list of all the operations present in the document when the first user opened the document and all the operations which the first user has added to the document since the first user opened the document. The operations which the first user has added to the document include those operations associated with the first user's edits to the document.

The first user edits the document and e-mails it to the second user. The second user opens the document with the second application. The second content module determines a semantically equivalent version of the document so that, once opened by the second application, the document will not have lost any data or formatting relative to how the document was rendered by the first application. In other words, upon being opened by the second application and processed by the second content module, the document is a semantic equivalent to how the document was rendered by the first application. This example is one of many implementations of the content module. Other example implementations of the content module are described below.

Embodiments of the present invention will be explained with reference to the accompanying drawings.

FIG. 1illustrates a block diagram of some implementations of a content management system100arranged in accordance with at least one embodiment described herein. The illustrated system100includes a first server101, a second server107, client devices103a,103b(also referred to herein individually and collectively as103), and a printer120. In the illustrated implementation, these entities of the system100are communicatively coupled via a network105.

The client devices103inFIG. 1may be used by way of example. WhileFIG. 1illustrates two client devices103a,103b, the present disclosure applies to a system architecture having one or more client devices103. Furthermore, althoughFIG. 1illustrates one network105coupled to the client devices103, the first server101, the second server107, and the printer120, in practice one or more networks105may be connected to these entities. Furthermore, whileFIG. 1includes one first server101, one second server107, and one printer, the system100could include any number of these elements (including zero).

The network105may be a conventional type, wired or wireless, and may have numerous different configurations including a star configuration, token ring configuration, or other configurations. Furthermore, the network105may include a local area network (LAN), a wide area network (WAN) (e.g., the Internet), or other interconnected data paths across which multiple devices may communicate. In some implementations, the network105may be a peer-to-peer network. The network105may also be coupled to or include portions of a telecommunications network for sending data in a variety of different communication protocols. In some implementations, the network105may include Bluetooth communication networks or a cellular communications network for sending and receiving data including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, e-mail, etc.

The first server101may be a hardware server that includes a processor, a memory, and network communication capabilities. The first server101may include a database or any other persistent storage. In the illustrated implementation, the first server101is coupled to the network105via signal line104. The first server101may send and receive data to and from one or more of the client devices103via the network105.

In some implementations, the first server101may be a collaboration server to provide one or more client devices103the functionality to collaboratively edit documents similar to Google Docs or any other collaboration web service. The first server101may also be an e-mail server, social network server, peer-to-peer service provider, or any other web service provider.

In some implementations, the first server101includes a content module199. The content module199may be code and routines for providing the functionality described below with reference toFIGS. 2-5Band7-14. In some implementations, the content module199may be implemented using hardware including a field-programmable gate array (“FPGA”) or an application-specific integrated circuit (“ASIC”). In some other implementations, the content module199may be implemented using a combination of hardware and software. In some implementations, the content module199may be stored in a combination of the client devices103and servers, or in one of the client devices103or servers. In some implementations, the content module199acts in part as a thin-client application that may be stored on the first server101and in part as elements that may be stored on the client device103. Accordingly, the content module199is depicted inFIG. 1using dashed lines and included in first server101, second server107, the first client device103a, and the second client device103bto indicate that any of these elements may include software, hardware, or a combination of hardware and software configured to provide some of the functionality of the content module199. The content module199is described in more detail with reference toFIGS. 2-5Band7-14.

The second server107is a hardware server that includes a processor, a memory, and network communication capabilities. The second server107may include a database or any other persistent storage. In the illustrated implementation, the second server107is coupled to the network105via signal line112. The second server107may send and receive data to and from one or more of the client devices103via the network105. The second server may provide functionality similar to the first server101described above. Accordingly, that description will not be repeated here.

The client device103may be a computing device that includes a memory and a processor. For example, the client device103may be a server, a laptop computer, a desktop computer, a tablet computer, a smartphone, a mobile telephone, a personal digital assistant (“PDA”), a mobile e-mail device, a portable game player, a portable music player, a television with one or more processors embedded therein or coupled thereto, or any other electronic device capable of executing applications or managing content. Managing content may include generating content, editing content, etc.

In the illustrated implementation, the first client device103ais communicatively coupled to the network105via signal line108and the second client device103bis communicatively coupled to the network105via signal line110.

The first client device103amay include a first application195a. The first application195ais code and routines for managing content. In some implementations the first application195amay be a word processor application, spreadsheet application, slideshow application, database application, diagram application, or mathematical formula editor, etc. For example, the first application195amay be any of the applications included in the Microsoft Office suite, LibreOffice suit, Apache OpenOffice suit, Apple iWork suite, or any other application capable of managing content such as a document, spreadsheet, slideshow, database, drawing, formula, etc.

The second client device103bmay include a first application195bsimilar to the first application195a. First applications195a,195bmay be referred to collectively herein as first application195.

The first client device103amay include a second application197a. The second application197ais code and routines for managing content. In some implementations the second application197amay be a word processor application, spreadsheet application, slideshow application, database application, diagram application, or mathematical formula editor, etc.

The second application197ais similar to the first application195awith the exception that the second application197ahas a different format than the first application195a. For example, the first application195ahas a .docx format and the second application197ahas an .odt format.

The second client device103bmay include a second application197bsimilar to the second application197a. Second applications197a,197bmay be referred to collectively herein as second application197.

The printer120is a hardware printer. The client device103may include a driver for communicating with the printer120. The client device103may print documents via the printer120. The printer120is communicatively coupled to the network105via signal line106. Optionally, the printer120may be directly coupled to a client device103.

Assume that second client device103bedits an .odt formatted document using the second application197b. The document is rendered on a monitor (not pictured) associated with the second client device103b. The second client device103be-mails the document to the first client device103avia the first server101, which in this example is configured as an e-mail server executing an e-mail application. The first client device103areceives the document in an e-mail via the network105. A user of the first client device103adesires to open and print the document using a first application195awhich uses .docx format. The first client device103auses the content module199to open and render a semantically equivalent version of the document using the first application. The first client device103asends instructions to the printer120to print the document. Since the document is a semantically equivalent version of the document relative to how it was rendered by the second client device103b, the printed document will have the same data and formatting as it did when rendered on the monitor associated with the second client device103b.

Referring now toFIG. 2, an example of the content module199is illustrated in accordance with at least one embodiment described herein.FIG. 2is a block diagram of a computing device200that includes a content module199, a first processor235, a memory237, and a communication unit245according to some examples. The elements of the computing device200are communicatively coupled by a bus220. In some implementations, the computing device200may be a server, such as the first server101or second server107ofFIG. 1. The computing device200may also be a client device, such as the client device103ofFIG. 1. In some implementations, the functionality of the computing device200is provided by two or more content modules199implemented across any combination of the first sever101, second server107, first client device103a, and the second client device103bas depicted inFIG. 1. In these embodiments, the two or more content modules199may include less than all of the sub-elements202,204,206,208,210,212,214depicted inFIG. 2.

The first processor235may include an arithmetic logic unit, a microprocessor, a general purpose controller, or some other processor array to perform computations and provide electronic display signals to a display device. The first processor235is coupled to the bus220for communication with the other elements via signal line236. The first processor235may process data signals and may include various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. AlthoughFIG. 2includes a single processor235, multiple processors may be included. Other processors, operating systems, sensors, displays, and physical configurations may be possible.

The memory237stores instructions or data that may be executed by the first processor235. The instructions or data may include code for performing the techniques described herein. For example, the memory237may store all the instructions or data necessary for the content module199to provide its functionality as described below with reference toFIGS. 2-5Band7-14.

The memory237is a non-transitory computer-readable storage medium. For example, the memory237may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or some other memory device.

In some implementations, the memory237also includes a non-volatile memory or similar permanent storage device and media including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for storing information on a more permanent basis. The memory237is coupled to the bus220via signal line238.

The communication unit245may transmit data to any combination of a client device103, first server101, second server107, and the printer120depending upon where the content module199may be stored. The communication unit245may receive data from any combination of a client device103, first server101, and second server107depending upon where the content module199may be stored. The communication unit245is coupled to the bus220via signal line246.

In some implementations, the communication unit245includes a port for direct physical connection to a network, such as a network105ofFIG. 1or to another communication channel. For example, the communication unit245may include a port such as a USB, SD, RJ42, or similar port for wired communication with a client device. In some implementations, the communication unit245includes a wireless transceiver for exchanging data with the client device or other communication channels using one or more wireless communication methods, including IEEE 802.11, IEEE 802.16, BLUETOOTH®, or another suitable wireless communication method.

In some implementations, the communication unit245includes a cellular communications transceiver for sending and receiving data over a cellular communications network including via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, e-mail, or another suitable type of electronic communication. In some implementations, the communication unit245includes a wired port and a wireless transceiver. The communication unit245also provides other conventional connections to a network for distribution of data using standard network protocols including TCP/IP, HTTP, HTTPS, and SMTP, etc.

In the implementation illustrated inFIG. 2, the content module199includes a communication module202, a run time module204, a design time module206, and a user interface module208. The user interface module208is depicted with a dashed line to indicate that it is an optional feature of the content module199. These elements of the content module199are communicatively coupled to each other via the bus220.

The communication module202is communicatively coupled to the bus220via signal line222. The run time module204is communicatively coupled to the bus220via signal line224. The design time module206is communicatively coupled to the bus220via signal line226. The user interface module208is communicatively coupled to the bus220via signal line228.

The communication module202may be software including routines for handling communications between the content module199and other elements of the computing device200. In some implementations, the communication module202may be a set of instructions executable by the first processor235to provide the functionality described below for handling communications between the content module199and other elements of the computing device200. In some instances, the communication module202may be stored in the memory237of the computing device200and may be accessible and executable by the first processor235.

The communication module202sends and receives data via the communication unit245, to and from one or more of a client device103, first server101, second server107, and printer120as depicted inFIG. 1.

In some implementations, the communication module202receives data from elements of the content module199and stores the data in the memory237. In some implementations, the communication module202retrieves data from the memory237and sends the data to one or more appropriate elements of the content module199. In some implementations, the communication module202receives data from one or more appropriate elements of the content module199or the memory237and sends the data to other elements of a system communicatively coupled to the computing device200, such as elements in the system100depicted inFIG. 1. The communication module202may be adapted for cooperation and communication with the first processor235and other elements of the computing device200via signal line222.

The run time module204may be software including routines for transforming a file from a first content type to a second content type. In some implementations, the run time module204is configured to provide the functionality described below with reference toFIGS. 3A-3Cand7-14. In some implementations, the run time module204may be a set of instructions executable by the processor235to provide the functionality described herein with reference toFIGS. 3A-3Cand7-14. The run time module204may communicate with the communication module202to access data from memory237or store data in the memory237. Examples of data accessed and stored by the run time module204include elements210,212,214,215,216,218.

In some implementations, the run time module204may include an operations producer297and an operations consumer299. The operations producer297and the operations consumer299are sub-modules of the run time module204that may be software including routines for providing the functionality described below with reference toFIGS. 3A-3Cand7-14.

In some implementations, the run time module204may be stored in the memory237of the computing device200and may be accessible and executable by the processor235. The run time module204may be adapted for cooperation and communication with the processor235and other elements of the computing device200via signal line224.

The design time module206may be software including routines for building the operations digest210, components digest212, and the properties digest214. In some implementations, the design time module206builds a single operations digest210describing all operations supported by the content module199. By contrast, the design time module206may build a paired set of a components digest212and a properties digest214for each format supported by the content module199.

For example, assume that the content module199supports the .odt format and the .doc format. The design time module206builds only one operations digest210even though the content module199supports two different formats, the .odt format and the .doc format. By contrast, the design time module206builds a different components digest212for each different supported format. The design time module206also builds a different properties digest214for each supported format. Accordingly, in this example the design time module206builds a first components digest212afor the .odt format and a second components digest212bfor the .doc format. Similarly, the design time module206also builds a first properties digest214afor the .odt format and a second properties digest214bfor the .doc format.

In some implementations, the content module199may support dozens, hundreds, or even thousands of different formats. In these implementations, the design time module206builds only one operations digest210describing the different operations supported by the content module199. However, the design time module206builds a different components digest212for each different supported format. The design time module206also builds a different properties digest214for each supported format.

In some implementations, the design time module206is configured to provide the functionality described below with reference toFIGS. 4 and 5. In some implementations, the design time module206may be a set of instructions executable by the processor235to provide the functionality described herein with reference toFIGS. 4 and 5. The design time module206may communicate with the communication module202to access data from memory237or store data in the memory237.

In some implementations, the design time module206may be stored in the memory237of the computing device200and may be accessible and executable by the processor235. The design time module206may be adapted for cooperation and communication with the processor235and other elements of the computing device200via signal line226.

The content module199may support any file format known in the art.

The user interface module208may be software including routines for generating a user interface. For example, the user interface module208accesses graphical data stored in the memory237(not pictured) and uses the graphical data to construct a user interface for display to a user of a client device103, first server101or second server107. The user interface may be used to provide a user input to the content module199. For example, the user provides an input selecting a format for rendering or saving a file associated with content.

In some implementations, the user interface module208may be stored in the memory237of the computing device200and may be accessible and executable by the processor235. The user interface module208may be adapted for cooperation and communication with the processor235and other elements of the computing device200via signal line228.

The memory237may store an operations digest210, one or more components digests212, one or more properties digests214, one or more sets of file data215associated with different content, one or more operations lists216associated with different file data215, and one or more combined operations lists218associated with different file data215. In one embodiment, the combined operations lists218for a given set of file data215is a modified operations list216and the memory only stores the combined operations list218.

The file data215is data describing the persistent form of content. The content may have any format. The file data215may be included in a file. The content may be a document and the file data215includes data describing the persistent form of the document, such as OOXML, HTML, and ODF. The content may include one or more semantic components or properties describing the semantic components. For example, the content may be a document that includes a paragraph of text that has a certain font or font color.

An operation is data that describes a change of a semantic component or property. For example, a user opens a new document. The user provides inputs to a word processing application to input text that forms a paragraph. The operations are data that describe the changes to the document. In this example, the operations are data that describe the semantics of the text and paragraph.

In some implementations, an operation is data that describes a change of the XML elements of attributes representing a semantic entity.

The operations list216is data describing an ordered sequence of operations included in the content described by the file data215. For example, the content is a new document that includes three paragraphs of text. The operations list216includes an ordered sequence of the operations necessary to create a second document that includes three paragraphs of text that are semantically equivalent to the three paragraphs included in the first document.

The combined operations list218is data describing two or more operations lists216that have been synchronized. For example, a user opens a new document and provides inputs to a word processing application to form three paragraphs of text having a certain format. The user may save the document. The document will have a first operations list216that describes the sequence of operations necessary to recreate the document. The user subsequently opens the document and changes the format of the three paragraphs and adds a fourth paragraph. The user may save this document as a new version. A second operations list216may include the sequence of operations that describe the changes to the semantic components and properties of the document. A combined operations list218includes the first operations list216synchronized with the second operations list216, and the operations included in the combined operations list218may be sequenced so that they may recreate the operations included in the new version of the document. In other words, the combined operations list218may include the sequence of operations included in the first operations list216followed by the sequence of operations included in the second operations list216.

In some implementations, the operations digest210, components digest212, and properties digest214include all the data and information necessary for the run time module204to provide its functionality. For example, the operations digest210, components digest212, and properties digest214include all the data and information necessary for the run time module204to provide the functionality described below with reference toFIGS. 3A-3Cand7-14.

The operations digest210is data describing one or more operations supported by the content module199.

The components digest212includes component data that describes all the semantic components that are supported by the content module199for a particular format. The properties digest214includes property data that describes all possible properties for the semantic components described by a given components digest212. The components digest212and the properties digest214are paired together for a specific format that is supported by the content module199. In other words, the components digest212is format specific. The properties digest214is also format specific. The system200may have a different components digest212and a different properties digest214for each format supported by the content module199. Each format supported by the content module199will be associated with one components digest212and one properties digest214.

As described above, the components digest212includes component data and the properties digest214includes property data. The semantic components described by the component data may also be described as the abstract components of content having a particular format. Examples of semantic components include a table, paragraph, characters such as text or numbers, etc. In some implementations, the semantic components are any part of content which may be added, deleted, or modified by user actions. For example, assume there is a format named .sva for a word processing document that includes only five semantic components that are supported by the content module199, and that these five semantic components are: headers; text; tables; images; and footers. Each of these semantic components may have one or more possible properties that are described by the properties data. At design time, the design time module206analyzes the .sva format and generates one components digest212and one properties digest214for the .sva format.

The components digest212and the properties digest214for a given format include all the data and information necessary for the run time module204to: analyze a first set of file data215for a file having a format that corresponds to the components digest212; identify the semantic components included in the file data215; determine which of these semantic components are related to operations supported by the operations digest210; and generate an operations list216or combined operations list218describing the supported operations included in the first set of file data215. The components digest212and properties digest214for a given format may also include all the data and information necessary for the run time module204to analyze an operations list216or combined operations list218and transform the sequence of operations included in the operations list216or combined operations list218to a second set of file data215that includes all the supported semantic components that were present in a first set of file data215. In some implementations, the second format is the same as the first format. The functionality of the components digest212will be described in more detail below with reference toFIGS. 3A-3Cand7-14.

In some implementations, the run time module204is configured to determine the schema for a set of file data215. The schema may be explicit or inferred. In some implementations, the run time module204may analyze a set of file data215to determine an explicit schema that describes the structure of the content. For example, the content may be a document and the run time module204analyzes the set of file data215to determine an explicit schema that describes the structure of the document. In this way the run time module204may determine an explicit schema for a set of file data215. In other implementations, the run time module204may analyze a set of file data215and infer the schema based on the structure of the content. A person having ordinary skill in the art will recognize that there may be other ways for the run time module204to determine the schema for a set of file data215.

In some implementations, the run time module204analyzes the input to determine a schema for the input. The schema may be explicit or inferred by the run time module204. The run time module204determines a first file format for a set of file data215based at least in part on the schema. The run time module204may determine a components digest212based at least in part on the schema. The run time module204may determine a properties digest214based at least in part on the schema.

Referring now toFIG. 3A, an example of the run time module204receiving an input (e.g.,370or372) having a first format and determining an output having a specified format which is semantically equivalent to the input.FIG. 3Ais illustrated in accordance with at least one implementation described herein.FIG. 3Amay be described as depicting an operations producer/consumer model300in accordance with one implementation.

FIG. 3Adepicts an operations producer297and an operations consumer299. The operations producer297and the operations consumer299are described in more detail below.

In some implementations, the operations producer297is a sub-module of the run time module204that receives an input and determines an operations list216or a combined operations list218. The operations producer297may receive different inputs370or372. The operations producer297may output an operations list216or a combined operations list218.

A first input370which the operations producer297may receive is first file data215A. The file data215A is data describing a file having a first file format. The file described by the file data215A may include any type of content. The content may include one or more operations. If the operations producer297receives the first input370, then the output of the operations producer297is an operations list216. The operations list216is data describing an ordered sequence of operations. The ordered sequence of operations which comprises the operations list216describes all supported operations present in the file data215A received by the operations producer297as the first input370.

In one implementation, the operations producer297receives the first input370. The operations producer297may retrieve an operations digest210from a memory237describing all the operations supported by the content module199. The operations producer297may analyze the file data215A to determine which operations are present in the file data215A. The operations producer297may determine which of these operations are supported by the content module199based on whether these operations are present in the operations digest210. The operations producer297may determine which format is associated with the file data215A. For example, the operations producer297may parse the file data215A or analyze the file name to determine the format of the file data215A. The operations producer297may utilize any other method known in the art for determining the format of the file data215A. The operations producer297may determine which components digest212A and which properties digest214A to use based on the file format. For example, each file format has a specific components digest212A and a specific properties digest214A. The operations producer297may retrieve the appropriate components digest212A and properties digest214A from the memory237based at least in part on the file format determined for the file data215A. The operations producer297may transform the supported operations present in the file data215A to an operations list216based on the components digest212A and the properties digest214A. The ordered sequence of operations which comprise the operations list216describe all the supported operations present in the file data215A received by the operations producer297as the first input370.

A second input372which the operations producer297may receive is one or more user inputs in an application195modifying file data215A having a first format. The file data215A is similar to that described above for the first input370, with the exception that a user has provided one or more inputs to the application195modifying the file data215A. For example, the file data215A describes a document and the application195is a word processor. The user provides one or more inputs to the application195associated with new operations for the file data215. The new operations can be any operations such as adding text, moving paragraphs, etc. In this situation, the operations producer receives second input372and outputs a combined operations list218. The combined operations list218describes all the operations present in the file data215A before the file data was modified as well as the additional operations added to the file data215A by the user inputs to the application195.

In one implementation, the operations producer297receives the second input372. The operations producer297may retrieve an operations digest210from a memory237describing all the operations supported by the content module199. The operations producer297may analyze the file data215A to determine which operations are present in the file data215A. The operations producer297may determine which of these operations are supported by the content module199based on whether these operations are present in the operations digest210. Similar to the description above for the first input370, the operations producer297may determine which format is associated with the file data215A; the operations producer297may further determine which components digest212A and which properties digest214A to use based on the file format. The operations producer297may retrieve the appropriate components digest212A and properties digest214A from the memory237based at least in part on the file format determined for the file data215A. The operations producer297may transform the supported operations present in the file data215A to a combined operations list218based on the components digest212A and the properties digest214A. The ordered sequence of operations which comprise the combined operations list218describe all the supported operations present in the file data215A received by the operations producer297as the second input372.

Accordingly, in some implementations the operations producer297receives an input that includes file data215A, determines which operations included in the file data215A are supported by the content module199based on an operations digest210, and outputs a list of operations (e.g., operations list216or combined operations list218) that describes all the supported operations present in the file data215A based on a components digest212A and a properties digest214A that are specific to the format of the file data215A. In some implementations, the operations list216or the combined operations list218are a lingua franca between the operations producer297and the operations consumer299.

In some implementations, the operations consumer299is a sub-module of the run time module204that receives an input and determines an output. The operations consumer299may receive the operations list216or the combined operations list218as an input. The operations consumer299may have different output depending on which type of input216or218is received.

In one implementation, the operations consumer299receives an operations list216as an input. The operations consumer299may retrieve an operations digest210from a memory237describing all the operations supported by the content module199. The operations producer297may analyze the operations list216to determine which operations are supported by the content module199; in some implementations, the operations consumer299skips this step and assumes that the operations present in the operations list216are supported by the content module199since the input of the operations list216was received from the operations producer297. The operations consumer299may determine a specified format for the operations list216. The operations consumer299outputs data having a specified file format. In some implementations, a human user of the content module199provides an input describing the specified format. In other implementations, the specified format may be a predetermined configuration of the consumer module199, or may be inferred by the content module199based on context data. The specified file format may be a format that is different from the first format of the file data215A. In some implementations, the specified format is the same as the first format. The operations consumer299may determine which components digest212B and which properties digest214B to use based on the specified file format. The components digest212B and the properties digest214B are configured to generate an output that is semantically equivalent to the input to the operations producer297. The operations consumer299may retrieve the appropriate components digest212B and properties digest214B from the memory237based at least in part on the specified file format. The operations consumer299may transform the supported operations present in the operations list216to second file data215B having the specified format. The second file data215B outputted from the operations consumer299is semantically equivalent to first file data215A. The operations consumer299transforms the operations list216based on the components digest212B and the properties digest214B.

In one implementation, the operations consumer299receives a combined operations list218as an input. The operations consumer299may retrieve an operations digest210from a memory237describing all the operations supported by the content module199. The operations producer297may analyze the combined operations list218to determine which operations are supported by the content module199; in some implementations, the operations consumer299skips this step and assumes that the operations present in the combined operations list218are supported by the content module199since the input of the combined operations list218was received from the operations producer297. The operations consumer299may determine a specified format for the combined operations list218. In some implementations, the specified format is the same as the first format. The operations consumer299may determine which components digest212B and which properties digest214B to use based on the specified file format. The components digest212B and the properties digest214B are configured to generate an output that is semantically equivalent to the input to the operations producer297. The operations consumer299may retrieve the components digest212B and properties digest214B from the memory237based at least in part on the specified file format. The operations consumer299may transform the supported operations present in the combined operations list218to specific functions of a second application197having the specified format. The functions specific to the second application197may then be rendered on a display. Upon being rendered on the display, the output will be semantically equivalent to how the first file data would have appeared had it been rendered on a display. Optionally, the functions may also be stored as second file data215B having the specified format. The second file data215B outputted from the operations consumer299is semantically equivalent to first file data215A. In some implementations, the operations consumer299transforms the operations in the combined operations list218to operations specific to a first application195that is the same as the application195in the second input372. The operations consumer299transforms the combined operations list218based on the components digest212B and the properties digest214B.

In some implementations, the operations producer297outputs an operations list216or a combined operations list218for a first application195. The output of the operations producer297may be the input for an operations consumer299that is specific to a second application197that is different from the first application. For example, the first application195is Microsoft Word and the second application is Apple Pages.

Referring now toFIG. 3B, an example of a method301for receiving, as an input, a first set of file data215A having a first format and outputting a second set of file data215B having a second format is described, in accordance with at least one embodiment described herein. The first format and the second format may be the same. The method301is described with respect toFIGS. 1-3A. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In the illustrated implementation ofFIG. 3B, the method301may include a run time module204receiving303the first input370described above with reference toFIG. 3A. The first input370may include a first set of file data215A having a first file format. The file data215A may describe any content such as a document, spreadsheet, webpage, etc. The run time module204may determine304a first file format for the file data215A included in the first input370. The run time module204may determine306a first components digest212A based on the first file format. The run time module204may determine308a first properties digest214A based on the first file format. The run time module204may determine309which operations are supported by the content module199based on an operations digest210. The run time module204may transform312the first file data215A to a list of operations using the first components digest212A and the first properties digest214A. The list of operations may be an operations list216. In some implementations, the list of operations may be a combined operations list218. The run time module204may determine314which operations included in the list of operations are supported by the content module199based on the operations digest314. For example, the run time module204determines that operations excluded from the operations digest210are not supported by the content module199. The run time module204may transform316the list of operations to a second set of file data215B having a second file format. The run time module204may save the data in a memory or communicate with the user interface module208to cause the content associated with the second set of file data215B to be rendered.

Referring now toFIG. 3C, an example of a method302for receiving, as an input, user inputs in an application195modifying a first set of file data215A having a first format and outputting a second set of file data215B having a second format is described, in accordance with at least one embodiment described herein. The first format and the second format may be the same. The method302is described with respect toFIGS. 1-3A. Although illustrated as discrete blocks, various blocks may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation.

In the illustrated implementation ofFIG. 3C, the method302may include a run time module204receiving380the second input372described above with reference toFIG. 3A. The second input372may include a first set of file data215A having a first file format. The file data215A may describe any content such as a document, spreadsheet, webpage, etc. The run time module204may determine382a first file format for the file data215A included in the first input370. The run time module204may determine384a first components digest212A based on the first file format. The run time module204may determine386a first properties digest214A based on the first file format. The run time module204may determine388which operations are supported by the content module199based on an operations digest210. The run time module204may transform390the first file data215A to a list of operations using the first components digest212A and the first properties digest214A. The list of operations may be an operations list216or a combined operations list218. The run time module204may determine392which operations included in the list of operations are supported by the content module199based on the operations digest210. The run time module204may transform394the list of operations to a set of application-specific functions. The run time module204may transform394the list of operations to a second set of file data215B having a second file format. The run time module204may save the data in a memory. The run time module204may save the data in a memory or communicate with the user interface module208to cause the content associated with the second set of file data215B to be rendered.

In some implementations, the run time module204is configured to determine the schema for the first input370. The schema may be explicit or inferred. In some implementations, the run time module204may analyze the data included in the first input370to determine an explicit schema that describes the structure of the content included in the first input370. For example, the content may be a document and the run time module204analyzes the first input370to determine an explicit schema that describes the structure of the document. In this way the run time module204may determine an explicit schema for a set of file data215. In other implementations, the run time module204may analyze the first input370and infer the schema based on the structure of the content. A person having ordinary skill in the art will recognize that there may be other ways for the run time module204to determine the schema for the first input370.

In some implementations, the run time module204analyzes the first input370to determine a schema for the first input370. The schema may be explicit or inferred by the run time module204. The run time module204determines304a first file format for the first input370based at least in part on the schema. The run time module204may determine306a components digest212based at least in part on the schema. The run time module204may determine308a properties digest214based at least in part on the schema.

Referring now toFIG. 4, an example graphical data flow model400of the design time module206creating an operations digest210, two components digests212A,212B, and two properties digests214A,214B is depicted.

On the left- and right-hand side ofFIG. 4are depicted two different types of inputs for the design time module206. On the left-hand side ofFIG. 4is a first application195and a second application197. For the purpose of example, the first application195may be a word processing application195and the second application197may be a spreadsheet application197. The applications195,197may be any type of application.

On the right-hand side ofFIG. 4is a first format410A schema and a second format410B schema. The first format410A schema corresponds to the first application195and the second format schema410B corresponds to the second application197, respectively. In other words, in this example the word processing application195has the first format410A schema and the spreadsheet application197has the second format410B schema.

Looking again to the left-hand side ofFIG. 4, the design time module206may determine which applications to support. For example, a user of the content module199provides an input to the design time module206specifying which applications to support. The design time module206may also determine which user scenarios to support. For example, a user of the content module199provides an input to the design time module206describing which user actions in an application should be supported by the content module199. A user scenario may be any user action with an application.

Looking again to the right-hand side ofFIG. 4, the design time module206may identify which file formats are supported by the input applications195,197. The design time module206may make this determination based on the first format schema410A and the second format schema410B.

Previously the design time module206determined which user scenarios to support. The design time module206now identifies the semantic components in the schemas that are required to support these user scenarios. For example, assume one of the user scenarios supported is moving text in the word processing application195. The schema which corresponds to the word processing application195is the first format schema410A. The design time module206analyzes the first format schema410A to identify the semantic components necessary to support moving text in a document of the word processing application195.

In some implementations, the design time module206analyzes a schema to identify a pattern of operations in the schema necessary to accomplish a supported user scenario. This process may be repeated for each supported user scenario.

The design time module206may analyze the schemas410A,410B associated with supported applications195,197to determine component metatypes for the supported user scenarios. For example, the design time module206determines one or more of a document root, delimiter, view, component(s), sub-component(s), etc.

The design time module206may analyze the first schema410A to determine data and information necessary to build a first components digest212A and a first properties digest214A. The first components digest212A and the first properties digest214A are associated with the first format410A for the first application195. The design time module206may also analyze the second schema410B to determine data and information necessary to build a second components digest212B and a second properties digest214B for the second format410B associated with the second application197. This analysis is described in more detail in the next paragraph.

For each component, the design time module206may identify the root element and other related element attributes that are mapped to the component. For each component, the design time module206may map the element attributes identified above to the properties of the component. The design time module206maps the components, properties, and application user scenarios to the operations that describe the components, properties, and application user scenarios. The result of this mapping is that the design time module206builds the operations digest210, components digests212A,212B, and properties digests214A,214B. The design time module206persists the digests210,212A,212B,214A,215B for subsequent use by the run time module204at run time.

Referring now toFIG. 5, an example of a method500for the design time module206building the operations digest210, components digest212, and properties digest214is described, in accordance with at least one embodiment described herein.

The design time module206receives502an input specifying an application to support. The design time module206receives504an input specifying which application user scenarios to support. The design time module206identifies506file formats for the selected applications. The design time module206identifies508semantic components required to support the application user scenarios specified at step504. For example, if one of the supported user application scenarios is “user adding text,” then the semantic components required to support this user application scenario might be: paragraph and text characters.

For each semantic component, the design time module206identifies510the root component element and other related elements mapped to the semantic component. In some implementations, each semantic component is associated with one or more adjacent XML elements that form a semantic unit. Each semantic unit may have a root component element. For each semantic component, the design time module206identifies the root component element as well as the other adjacent XML elements that formed the semantic unit associated with that semantic component. For example, in .ODF the component element “table” may be associated with <table:table>. The design time module206may determine the root component element and other related elements for “table.”

In some implementations, there may be three methods used by the design time module206to identify510a root component element of a semantic component. The first way is referred to as the “empirical method.” For example, the empirical method includes: the design time module206opens an application that supports the semantic component and the format of the semantic component; the design time module206opens a file format document using the application; the design time module206provides an input to the application to add a semantic component to the file format document of the application; the design time module206saves the file format document; the design time module206analyzes the file format document to determine the differences; and the design time module206determines the root component element for the semantic component based on the differences.

The second method is referred to as the “explicit method.” For example, the explicit method includes: the design time module206accesses the specification of the format associated with the semantic component; and the design time module206analyzes the specification to determine the root component element for the semantic component.

The third way is a mix of the empirical method and the explicit method; this method is referred to as the “composite method.”

In some implementations, the design time module206builds the components digest212by implementing one or more aspects of steps508and510. In some implementations, an intermediate step is to determine the operations necessary in each supported application to achieve each of the supported user action scenarios. The design time module206may then map each supported user action scenario to the one or more operations necessary to achieve that user action scenario.

As described above for step508, each supported application user scenario is mapped to one or more semantic components necessary to achieve that user application scenario. For each semantic component, the design time module206maps512the attributes of the semantic component to the properties512of the semantic component.

In some implementations, the design time module206maps512the attributes of the semantic component to the properties512of the semantic component using methods similar to those described above with reference to step510. When applying the empirical method, a component is not added to the file format document. Instead, the design time module206alters each possible property for the semantic component by providing inputs to the application and determines the changes. In this way the design time module206may determine the properties for the semantic component and how the properties are mapped to the semantic component.

In some implementations, each application user scenario is mapped to one or more semantic components necessary to achieve that user application scenario. In this way each supported user application scenario is associated with the one or more semantic components necessary to achieve the user application scenario. Since each semantic component is mapped to one or more properties, each supported user application scenario is associated with the one or more semantic components and the properties that are mapped to each of these semantic components.

In some implementations, the design time module206builds the properties digest214by implementing one or more aspects of step512.

Each supported application user scenario is associated with the one or more operations necessary to achieve the supported application user scenario. Each supported user application scenario is associated with one or more semantic components and one or more properties mapped to these semantic components. For each supported application user scenario, the design time module206maps514the semantic components associated with the application user scenario and the properties associated with the application user scenario to each operation necessary to achieve that application user scenario. The design time module206persists516the results of this mapping.

Referring now toFIG. 6, a prior art method600for an application translating an edit event at run time is described. In the prior art method600all knowledge of how the format schema relates to user actions and functionality in an application is contained solely within the application itself.

A user provides an input requesting the application to open an editor. The application opens602the editor. The user provides an input describing a user action. The application receives606the input describing the user action. The application determines608what type of action is associated with the user input. The application retrieves and applies610an application-specific file input/output logic. The user provides an input such as keystrokes to create a document or any other input to edit a document in the editor. This may be described as an edit event. The application receives612the user inputs associated with the edit event. The application614provides functionality or rendering appropriate for the edit event.

Referring now toFIG. 7, an example of a method700for the content module199translating an edit event for content at run time is described, in accordance with at least one embodiment described herein. Method700concerns a method for a single user to manage content using the content module199. In the method700all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A user provides an input requesting the application to open an editor. The application opens702the editor and the content module199retrieves an operations digest210. The user provides an input describing a user action. The user may be creating new content or editing previously created content. For example, the content is a document and the user may be creating a new document or editing a previously created document. In some implementations, the content is a template.

The content module199receives706the input describing the user action. The content module199determines708what type of action is associated with the user input. For example, the content module199determines708whether the user is creating new content or editing previously created content.

The content module199may also determine a schema for the content. The schema may be explicit or inferred by the content module199. The content module199may determine a first format for the content based on the schema. The content module199may further determine a first components digest212A and a first properties digest214A based on the schema or the format.

The user provides an input such as keystrokes to create content or any other input to edit previously created content in the editor. This may be described as an edit event. The content module199receives712the user inputs associated with the edit event. The user inputs may be associated with one or more operations. The content module199determines which operations are associated with the user inputs using the first components digest212A and the first properties digest214A. The content module199determines714whether the operations are supported by the operations digest210. For example, the content module199maps the input to an operation in the operations digest210to determine the operation represented by the input. The content module199uses the operations associated with the user inputs to generate716a list of operations. The list of operations may be a combined operations list218or an operations list216.

The content module199may determine a specified format. The specified format may be the same as the first format or different from the first format. In some implementations, the user provides an input describing the specified format. For example, the user requests that the content be saved according to the specified format. If the specified format is different than the first format, then the content module199may determine a second components digest212B and a second properties digest214B based on the specified format. The content module199may transform the operations in the list of operations to file data215having the specified format. The content module199may save718the file data215for the content having a specified file format.

Referring now toFIG. 8A, an example of a method800for the content module199to translate an edit event for content at run time is described, in accordance with at least one embodiment described herein. Method800concerns a method for one or more users to synchronously manage content using the content module199. In the method800all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A first user provides an input requesting the application to open an editor. The application opens802the editor and the content module199retrieves an operations digest210. The first user provides an input describing a user action. The first user may be creating new content or editing previously created content. The first user may be collaborating on the content with a second user. For example, the content is a document and the first user and the second user may be collaborating to create a new document or edit a previously created document. In some implementations, the content is a template.

The content module199receives806the input describing the user action. The content module199determines808what type of action is associated with the user input. For example, the content module199determines808whether the user is creating new content or editing previously created content.

In some implementations, the content module199may also determine a schema for the content. The schema may be explicit or inferred by the content module199. The content module199may determine a first format for the content based on the schema. The content module199may further determine a first components digest212A and a first properties digest214A based on the schema or the format. The content module199may determine an initial operations list216for the content. The initial operations list216may describe the state of the content prior to the content being edited or modified by the first user or the second user.

The first user provides an input such as keystrokes to create content or any other input to edit previously created content in the editor. The second user may provide additional inputs modifying the content. This may be described as a first edit event. The content module199receives812the user inputs associated with the first edit event. The user inputs may be associated with one or more operations. The content module199determines which operations are associated with the user inputs using the first components digest212A and the first properties digest214A. The content module199determines814whether the operations are supported by the operations digest210. For example, the content module199maps the input to an operation in the operations digest210to determine the operation represented by the input. The content module199uses the operations associated with the user inputs to generate816a first combined operations list218A.

In some implementations, the first combined operations list218A includes operations that are synchronized based on the order in which the inputs of the first user and the second user were provided. For example, the first user provides one or more inputs to the content module199that are stored in a first user operations list associated with the first user. The second user provides one or more inputs to the content module199that are stored in the second user operations list associated with the second user. The content module199determines816the first combined operations list218A by merging the first user operations list and the second user operations list. The content module199may merge the operations lists by sequencing the operations from the first user operations list and the second user operations list in the order that each operation was provided by the first user and the second user. The first combined operations list218A may include operations in the initial operations list216and operations associated with the first inputs from the first user and the second user.

Referring now toFIG. 8B, the first user provides an input such as keystrokes to create content or any other input to edit previously created content in the editor. The second user may provide additional inputs modifying the content. This may be described as a second edit event. The content module199receives818the user inputs associated with the second edit event. The user inputs may be associated with one or more operations. The content module199determines which operations are associated with the user inputs using the first components digest212A and the first properties digest214A. The content module199determines820whether the operations are supported by the operations digest210. For example, the content module199maps the input to an operation in the operations digest210to determine the operation represented by the input. The content module199uses the operations associated with the user inputs to generate822a second combined operations list218B.

In some implementations, the content module199may generate822the second combined operations list218B by merging the operations lists of the first user and the second user. The second combined operations list218B may include operations that are synchronized based on the order in which the inputs of the first user and the second user were provided. For example, the first user provides one or more second inputs to the content module199that are stored in a first user operations list associated with the first user. The second user may provide one or more second inputs to the content module199that are stored in the second user operations list associated with the second user. The content module199determines818the second combined operations list218B by merging the first user operations list (for the second inputs) and the second user operations list (for the second inputs). The content module199may merge the operations lists by sequencing the operations from the first user operations list (for the second inputs) and the second user operations list (for the second inputs) in the order that each operation was provided by the first user and the second user. The second combined operations list218B may include operations in the initial operations list216, the first combined operations list218A and operations associated with the second inputs from the first user and the second user. Each of the operations included in the second combined operations list218B may be sequenced as described based on the order in which they were provided.

The content module199may determine a specified format. The specified format may be the same as the first format or different from the first format. In some implementations, the user provides an input describing the specified format. For example, the user requests that the content be saved according to the specified format. The content module199may transform the operations in the second combined operations list218B to file data215having the specified format. The content module199may save824the file data215for the content having a specified file format.

Referring now toFIG. 9, an example of a method900for the content module199to translate an edit event for content at run time among two or more applications used by one user is described, in accordance with at least one embodiment described herein. Method900concerns a method for a user to manage content among two or more applications using the content module199. In the method900all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A user provides an input requesting a first application to open a first file. The first application may have a first schema and a first format. The content module199may determine the first schema. The first schema may be explicit or inferred by the content module199. The content module199may determine the first format. The content module199may determine the first format based on the first schema.

The content module199receives902the input requesting that the first application open the first file. The user provides an input to the first application editing the content of the first file. The content module199receives906the input editing the content of the first file. The operations associated with the inputs to the first application editing the content of the first file may be saved to a first operations list216A.

The user provides an input to a second application requesting that the second application open the first file. The first application may have a second schema and a second format. The content module199may determine the second schema. The second schema may be explicit or inferred by the content module199. The content module199may determine the second format. The content module199may determine the second format based on the second schema. The first format and the second format may be the same format.

The content module199receives912the input from the user requesting that the second application open the first file. The user provides an input to the second application editing the content of the first file. The content module199receives914the input editing the content of the first file. The operations associated with the inputs to the second application editing the content of the first file may be saved to a second operations list216B.

The content module199determines916A combined operations list218. The content module199may determine the combined operations list218by merging the first operations list216A and the second operations list216B.

The content module199may transform the operations in the second combined operations list218B to file data215having a specified format. The content module199may save918the file data215for the content having a specified file format.

Referring now toFIG. 10, an example of a method1000for two or more users to use the content module199to synchronously edit content at run time is described, in accordance with at least one embodiment described herein. Method1000concerns a method for two or more users to manage content among two or more applications using the content module199. In the method1000all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A first user and a second user are synchronously editing1002a first file. In some implementations, the first user and the second user are contemporaneously editing the first file. The first user may be using a first application having a first format. The second user may be using a second application having a second format. The content module199may receive1006a first input from a first user editing the first file using the first application. The content module199may determine a first operations list216A based on the first inputs from the first user. The content module199may receive1014a second input from a second user using the second application. The content module199may determine a second operations list216B based on the second inputs from the second user. The content module199may exchange1016operations between the first operations list216A and the second operations list216B in real time so that the first user and the second user may collaborate on the creation of content even though they may be using different applications that may have different formats. The operations lists216A,216B may be used by the content module199to translate the file data for the file to the formats of the first application and the second application, respectively. The content module199may save1018the file according to a specified file format.

Referring now toFIG. 11, an example of a method1100for two or more users to use the content module199to asynchronously edit content at run time is described, in accordance with at least one embodiment described herein. Method1100concerns a method for two or more users to manage content among two or more applications using the content module199. In the method1100all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A first user and a second user are asynchronously editing1102a first file. The first user may be using a first application having a first format. The second user may be using a second application having a second format. The content module199may determine1104that the first user is the active user. In other words, the first user is the user presently editing the content. The content module199may receive1106a first input from a first user editing the first file using the first application. The content module199may determine a first operations list216A based on the first inputs from the first user.

The content module199may determine1107that the second user is the active user. Responsive to determining that the second user is the active user, the content module199may transmit1108the first operations list216to the second application. The content module199may receive1110a second input from the second user editing the first file using the second application. The content module199may determine a second operations list216B associated with the second inputs. The content module199may determine combined operations list218by merging the first operations list216A and the second operations list216B. The content module199may determine1112that the first user is the active user. The content module199may transmit1114the combined operations list218to the first application.

Referring now toFIG. 12, an example of a method1200for two or more users to use the content module199to asynchronously edit content at run time from shared storage or a shared connection is described, in accordance with at least one embodiment described herein. Method1200concerns a method for two or more users to manage content among two or more applications using the content module199. In the method1200all knowledge of how the format schema relates to the user action scenarios and functionality in the application is contained within the operations digest210of the content module199.

A first user and a second user are asynchronously editing1202a first file from shared storage or a shared connection. The first user may be using a first application having a first format. The second user may be using a second application having a second format. The content module199may receive1206a first input from a first user editing the first file using the first application. The content module199may determine a combined operations list218based on the first inputs from the first user and the initial state of the content in the first file. The content module199may store1208the combined operations list.

The content module199may receive1214a second input from the second user editing the first file using the second application. The content module199may update1216the combined operations list to include the operations associated with the second inputs. The content module199may save1218the file data according to a specified format.

Referring now toFIG. 13A, an example of a method1300for the content module199to merge two or more operations lists216is described, in accordance with at least one embodiment described herein. The content module199receives1302a first operations list216A for a first document having a first format. The content module199receives1306a second operations list216B for a second document having a second format. The content module199merges1312the first and the second operations lists216A,216B to form a combined operations list218that includes a sequence of all the operations included in the first operations list216A and all the operations included in the second operations list216B. The sequence of the operations in the combined operations list218may be based on the time each operation was received. In some implementations, operations from one of the operations lists216A,216B may cancel or modify operations in the other operations list, and the combined operations list218may include operations to reflect the cumulative effect of these operations. In some implementations, the combined operations list218may be used to generate a third document that includes the operations included in the combined operations list218.

Referring now toFIG. 13B, a block diagram is depicted illustrating a merge operation1399performed by the content module199for a first user's stack and a second user's stack. The alphabet characters inFIG. 13Brepresent operations in content. The numerical characters following the alphabet characters represent the position of the operations in the content. For example, consider the first user's stack in element1390. At the top of the stack is “C3.” Here, “C3” represents an operation referred to as “C.” The “C” operation is the “3” position of the content.

Referring now to element1390, a first user has added operation A. The first user's stack indicates that operation A was received first in time because operation A is at the bottom of the stack. Operation A is at the “1” position in the content. Next in time the first user added operation B. Operation B is at the “2” position in the content. Then the first user added operation C. Operation C is at the “3” position in the content.

Still referring to element1390, the second user has added operation D. The second user's stack indicates that operation D was received first in time because operation D is at the bottom of the stack. Operation D is at the “1” position in the content. Next in time the second user added operation E. Operation E is at the “2” position in the content. Then the second user added operation F. Operation F is at the “3” position in the content.

In this example, the second user's operations occurred later in time relative to the first user's operations. Accordingly, we would expect that the second user's operations will be at the top of the first user's stack once the merge is completed.

Referring now to element1392, the content module199begins to merge the second user's stack to the first user's stack. To merge the stacks, the content module199moves the bottom single card of the second user's stack and moves it to the bottom of the first user's stack.

Referring to element1394, the content module199switches the two operations and changes the position of operations accordingly. This process is repeated. Looking at the third depicted iteration, operation D is in the first user's stack and placed at the “4” position of the content. The first user's stack indicates that operation D was received later in time than operations C, B, or A since operation D is at the top of the first user's stack.

Referring to element1396, the content module199repeats the process described above until the F, E, and D operations are in the first user's stack. The first user's stack indicates that operation F was received later in time than operations E, D, C, B, or A since operation F is at the top of the first user's stack.

Referring now toFIG. 14, an example of a method1400for two or more applications each having different formats to exchange macros is described, in accordance with at least one embodiment described herein. Two different applications implement different content modules199A,199B. For example, a first application195implements a first content module199A and a second application197implements a second content module199B. The first application195has a first format and the second application197has a second format. The first format and the second format are different. The first application195may have a different schema than the second application197. The content modules199A,199B enable the applications195,197to exchange a macro without knowledge or coordination between the applications195,197. The macro may be configured to modify content.

A user creates1402a first macro for the first application195having a first format. The first application195has a first format. The user may save the macro. The first content module199A may create1406an operations list216(or combined operations list218) describing the macro. The first content module199A may create the operations list using a first components digest212A and a first properties digest214A selected by the first content module199A based on the schema or format of the macro. The first content module199A may be associated with the first application195. The first content module199A may save the operations list216(or combined operations list218). The user opens a second application197having a second format that is different from the first format. The second application197may be associated with a second content module199B. The user may provide an input to execute the macro in the second application197. The second content module199B may analyze the macro to determine the format of the macro. The second content module199B may retrieve1414a second components digest212A and a second properties digest214B. The second content module199B may use the second components digest212B and the second properties digest214B to transform1416the operations list216(or combined operations list218) to a form usable by the second application197. In some implementations, the second content module199B may transform the operations to form a second macro usable by the second application197. In other implementations, the second content module199B may use the operations list216(or combined operations list218) to generate signals or commands that are transmitted to the second application197; the signals or commands may be configured to achieve the functionality of the first macro in the second application.

FIGS. 15-20illustrate an example of content being processed by the content module199. Element1500is depicted inFIG. 15. Element1600is depicted inFIG. 16. Element1700is depicted inFIG. 17. Element1800is depicted inFIG. 18. Element1900is depicted inFIG. 19. Element2000is depicted in FIG.2-. Elements1500,1600,1700,1800,1900and2000depict the content represented by element1500being processed by the content module199from a first format (e.g., .XML) to a specified format (e.g., JSON) that is different from the first format, and then transformed back to the first format as shown in element2000. This is an example of a “roundtrip transformation.”

In one implementation,FIG. 15depicts a first content1500in a start document, according to some embodiments. For example, the first content1500is a document. The first content1500is a snippet of XML from an ODF text document. For example, the first content1500is a subset of the content.xml file, which is zipped as part of the overall OpenDocument Text document. The first content1500shows a sequence of three paragraphs (or paragraph components). The first paragraph contains only a character “A,” the last the character “B,” and the middle paragraphs contains an image component which is referenced from the Internet, using the hypothetical locator “http://home/pic.png.” This locator is only being used by way of example, and not to incorporate content into this detailed description. In this example the image component consists in opposite of the singular paragraphs out of two XML elements, <text:frame> and the containing <text:image>. The design idea of ODF was that the text:frame only contains the size and consistency of the frame, here 26 millimeter square, while there might be multiple content elements within the frame, where the first applicable by the application is being shown. Here, only one image element is included. In some embodiments, there is an OLE XML element followed by an image to provide a view on Linux systems not capable of Windows OLE entities.

FIG. 16depicts the first content1500of the start document as first operations1600in JSON (JavaScript Object Notation), according to some embodiments. Here the first operations1600are a sequence of operations. This may be an example of an operations list216. In this example the value of the “name” property is a concatenation of the operation metatype (here only “insert”) and the component name, here Paragraph, Text and Image. The argument “attrs” contains all component properties, like the locator or size of the image. In this example all length measurements have been normalized to a 100th of millimeter as common denominator. In this example the “start” parameter defines the position of the component addressed at the time when the operation was executed. Here it starts similar as XML with “1” as first component. “1,1” indicates the first child of the first component, and so on. As a document had been loaded, all operations are sorted in document order and only insert document exist. It is a condensed sequence of operations, or a normalized operations sequence.

FIG. 17depicts the first content1500of the start document rendered as a second document1700in an editor, according to some embodiments. Element1700includes three paragraphs with its content: (1) the “A”; (2) the image; and (3) the “B.” Also depicted in element1700is a cursor behind the “B” ready to accept a new user input.

FIG. 18depicts edited content1800, according to some embodiments. Here, the start document shown inFIG. 15is edited in an editor to form edited content1800. Edited content1800includes a new paragraph with the content “C” that was not included in the start document.

FIG. 19depicts the edited content1800as second operations1900in JSON, according to some embodiments. This may be an example of a combined operations list218. The second operations1900includes a combined operation sequence of the loaded document and user actions. The second operations include two new operations new operations (here separated by an empty line for visibility) not present in the first operations1600: the insertion of text in the exiting third paragraph; and the split of the paragraph into a new forth one, just before the new inserted “C” moving this letter to the new paragraph.

FIG. 20new content2000in an end document based off the second operations1900, according to some embodiments. The second operations have been transformed by the content module199back to an OpenDocument Text file, where again we only see a subset of the content.xml of the zipped package for the sake of simplicity. The new content2000includes a new XML element <text:p>C</text:p> where one letter “C” had been added at the end of the content2000.

The embodiments described herein may include the use of a special purpose or general purpose computer including various computer hardware or software modules, as discussed in greater detail below.

Embodiments described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media may include tangible computer-readable storage media including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices), or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general purpose or special purpose computer. Combinations of the above may also be included within the scope of computer-readable media.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used herein, the terms “module” or “component” may refer to specific hardware implementations configured to perform the operations of the module or component and/or software objects or software routines that may be stored on and/or executed by general purpose hardware (e.g., computer-readable media, processing devices, etc.) of the computing system. In some embodiments, the different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads). While some of the system and methods described herein are generally described as being implemented in software (stored on and/or executed by general purpose hardware), specific hardware implementations or a combination of software and specific hardware implementations are also possible and contemplated. In this description, a “computing entity” may be any computing system as previously defined herein, or any module or combination of modulates running on a computing system.