RU2417420C2 - Programmability for xml data store for documents - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: system includes a processor, a computer readable carrier; applications which consume data; document data store; and a data store connected to applications which consume data, wherein the data store includes: an XML data store, API broker; a changes store which is adapted to store changes; and a cancellation store which is adapted to chancel any changes made after a change which was made to structured data elements; the API broker provides an application programming interface (API), which provides programmed access to documents and the structured data element, which are contained in the data store; and the application can execute the API to access structured data elements in data stores when the document is open or closed.

EFFECT: high reliability of resolving access conflicts and data editing.

16 cl, 5 dwg

Description

State of the art

Computer users are getting more and more used to user-friendly application software that helps them write, calculate, organize, prepare presentations, send and receive e-mail, compose music, etc. For example, text editor applications allow users to prepare various useful documents. Applications - spreadsheets allow users to enter data, manipulate it and organize data. Applications - slide presentations allow users to create various slide presentations containing text, images, data or other useful objects.

Documents created by such applications (for example, text editor documents, spreadsheets, documents - slide presentations), however, have limited capabilities for storing / transporting the content of arbitrary metadata required by the document context. For example, a solution built on top of a text editor document may require storing data for clerical work that describes various document states, for example, previous confirmed states during clerical work (dates, times, names), current approval states, future clerical states until work is completed document, name and office of the author of the document, document changes, etc. Possible options for storing this information are mainly limited by the use of document variables or the existing properties of linking and embedding document objects (OLE, CBO), which have limitations. For example, it is not possible to store hierarchical data; the length of the character is limited, etc. The properties of such methods are stored in one store, for example, the OLE property store, which means that conflicts can occur between properties. In addition, such stored properties do not have the ability to validate data. It is difficult for a user of such applications and related documents to store arbitrary data along with documents that are often required by many users.

SUMMARY OF THE INVENTION

This section "Summary of the invention" is intended to introduce in a simplified form the selected concepts, which are described in more detail below in the section "Detailed description of the invention". This section "Summary of the invention" is not intended to identify the main properties or essential properties of the claimed subject matter, nor is it intended to be used as a means of determining the scope of the claimed subject matter.

One or more data storages are contained separately from the primary presentation repository in a document for storing, collating and enabling the use of arbitrary data that is associated with a document created on a computer. Data for structuring information associated with a document, such as document metadata, is contained in a data warehouse that maintains relationships between different pieces of data. The data warehouse provides application programming interfaces (APIs, APIs) for various parts of the data that are in the data warehouse, which provides for different applications the ability to access and operate on one or more of these data parts.

Parts of the data may be structured according to a markup language, such as, for example, an extensible markup language (XML, PHP). XML schemas can be associated with each piece of data, and the data store can validate the XML structure attached to the data based on the XML schema associated with that piece of data. Programmatic access is provided to data in their XML form during document editing. Many client applications can access and edit the same parts of the document data, and any conflicting changes to this part of the data are allowed. Standard XML Schemas (XSD, OCP, XML Schema Definition) can also be used to determine the content of any parts of the specialized XML data associated with the document metadata, to ensure the validity of the XML data applied to the document data.

Brief Description of the Drawings

Figure 1 illustrates an exemplary computing architecture for a computer;

figure 2 shows a block diagram illustrating the relationship between one or more client applications and one or more data stores and the contents of the data store (s);

Figure 3 illustrates a system diagram representing the interaction between internal and external data consumers with XML data stores;

figure 4 illustrates the process of processing events that are associated with a data warehouse;

5 illustrates an event processing process that includes side effects in accordance with aspects of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Various aspects of the present invention will be described below with reference to the drawings, in which the same reference numerals denote the same elements. In particular, FIG. 1 and the corresponding description are intended to provide a brief, general description of an appropriate computing environment in which embodiments of the invention may be embodied.

Typically, program modules include procedures, programs, components, data structures, and other types of structures that perform specific tasks or embody specific types of abstract data. Other computer system configurations may also be used, including portable devices, multiprocessor systems, microprocessor-based electronic devices or programmable household electronic devices, mini-computers, large electronic computers, and the like. You can also use distributed computing environments in which tasks are performed by remote processing devices connected through a data network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Figure 1 shows one exemplary system for implementing the invention, which includes a computing device, such as computing device 100. In the simplest configuration, computing device 100 typically includes at least one processor device 102 and system memory 104. Depending on the exact configuration and type of computing device, system memory 104 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or be a combination of these two. System memory 104 typically includes an operating system 105, one or more applications 106, and may include program data 107. In one embodiment, the application 106 may include a text editor application 120. Such a basic configuration is illustrated in FIG. 1, and these components are represented internally by dashed line 108.

Computing device 100 may have additional properties or functions. For example, computing device 100 may also include additional (removable and / or non-removable) data storage devices, such as, for example, magnetic disks, optical disks, or tape. Such additional drives are shown in FIG. 1 as a removable drive 109 and a non-removable drive 110. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information, such as computer readable instructions , data structures, program modules or other data. System memory 104, removable storage 109 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, flash memory or another technology storage device, CD-ROM, digital versatile disks (DVD) or other optical drives, magnetic tapes, magnetic tape, magnetic disk drive or other magnetic information storage devices, or any other medium that can be used to store the required information and which can be accessed by computer device 100. Any such computer storage medium for storing computer information may be part of a device 100. Computing device 100 may also have input device (s) 112, such as a keyboard, mouse, pen, voice input device, touch input device, etc. . Output device (s) 114, such as a display, speakers, printer, etc., may also be included. These devices are well known in the art and a detailed description thereof is not required.

Computing device 100 may also include a data connection 116 that allows the device to communicate with other computing devices 118, for example, through a network. The data connection 116 is one example of a data medium. Media can usually be implemented using computer-readable instructions, data structures, program modules or other data in the form of a modulated data signal, such as a carrier wave or other transport mechanism, and include any information delivery medium. The term "modulated data signal" means a signal, one or more of whose characteristics are set or changed in such a way as to encode information in the signal. By way of example and without limitation, the data transmission medium includes a wired medium, such as a wired network or a direct wired connection, and a wireless medium, such as acoustic, RI, infrared, and other wireless medium. The term "computer-readable storage medium", as used in the present description, includes both storage media and media.

A number of program modules and data files can be stored in the system memory 104 of the computing device 100, including an operating system 105 that is designed to control the operation of a networked personal computer, such as the WINDOWS operating system of the MICROSOFT Corporation of Redmond, Washington. The system memory 104 may also store one or more program modules, such as a text editor application 120, and other modules described below. The application 120 of the text editor during operation provides the functions of the formation, editing and processing of electronic documents.

In accordance with one embodiment of the invention, the text editor application 120 comprises a WORD program from MICROSOFT Corporation. However, it should be understood that you can use the program application text editor from other manufacturers. The text editor application is presented in the drawing as an example only and is not limited to other types of applications that can generate documents and allow you to perform operations with documents. For example, other applications 106 that allow you to process various forms of content (for example, text, images, etc.), such as applications - spreadsheets, applications - databases, applications - slide presentations, drawing applications or CAD programs, etc. equally applicable. An example application 106 that generates and allows operations with other types of documents includes an OFFICE application from MICROSOFT Corporation.

Embodiments may be implemented as a computer process, a computer system, or as a production product, such as a computer program product or a computer readable medium. The computer program product may be a computer storage medium readable by a computer system, and in which a computer program is encoded, consisting of instructions for performing the computer process. A computer program product may also be a carrier propagating signal read by a computing system and in which a computer program is encoded consisting of instructions for performing a computer process.

Throughout the description and in the claims, the following terms have the meanings associated here, unless the context of these terms dictates otherwise.

The term “data” may refer to information at the surface level of a document or presentation level, such as words, sentences, paragraphs, etc., as well as supporting information, such as metadata, that is carried along with a text editor document that relates to it or which are used by a text editor document. Such information is often voluminous and, as a rule, it does not represent at the level of presentation of the document.

The term “presentation” refers to the visible part of a document, such as text and layout, which may occur if the document was printed.

The term tag refers to characters inserted in a document that delimit elements in an XML document. Each element typically includes two tags: the start tag and end tag. It is also possible to use an empty element (no content), and in this case, be allowed to use a single tag.

The terms “markup language” or “ML” (NR) refer to the language for special codes contained in a document that define how parts of the document should be interpreted by the application program. In a text editor file, the markup language determines how the text should be formatted or composed.

The term "element" refers to the core module of an XML document. An element may contain attributes, other elements, text, and other content areas for an XML document.

The term “building block” refers to a related and potentially labeled area in a document that is used as a container for a particular type of content entered by a user.

The term “data binding, data mapping, and data field” refers to a building block property that defines XPath for the XML DOM stored in the document where the contents of the building block should be stored.

The content (content) of the XML between the tags is treated as the "children" (or descendant) of the element. Therefore, other elements embedded in the content of an element are called “children” or “child nodes” or element. Text embedded directly in the content of an element is considered to be "child text vertices of the element." Together, the child elements and the text in the element make up the "content" ("content") of the element.

The term “attribute” refers to an additional property set for a particular value and associated with an element. Elements can have an arbitrary number of attribute settings associated with them, including zero. Attributes are used to associate additional information with an element that will not contain additional elements or will not be considered as a text vertex (node).

"XPath" is an operator that uses a path expression to identify nodes in an XML document. The XPath path is a slash-separated list of child element names that describe the path through an XML document. The structure "selects" the elements that correspond to this path.

The term “XML data warehouse or data warehouse” refers to a container in a document, such as a text editor document, a spreadsheet document, a slide presentation document, etc., that provides access for storing and modifying data (for example, in XML format ) saved in the document when the file is open. An additional definition of an XML data store is presented below with reference to FIG.

Figure 2 shows a block diagram illustrating the relationship (relationship) between one or more child applications and one or more data stores and the contents of the data store (s). In general terms, one or more data warehouses are contained separately from the primary representation store in a document for storing, collating, and for enabling the use of arbitrary data that is associated with a computer-generated document. Data for structuring the information associated with the document, such as document metadata, is contained in a data warehouse, where relationships between different pieces of data are maintained. The data warehouse provides application programming interfaces (APIs) for various pieces of data in a data warehouse, providing the ability to access and perform operations for various applications with one or more pieces of data. Used in this description, the terms "data consumers", "application programs" and "processes" can be used interchangeably, unless the context clearly dictates otherwise.

Parts of the data may be structured according to a markup language, such as an extensible markup language (XML). XML schemas can be associated with each piece of data, and the data store can validate the XML structure applied to the data based on the XML schema associated with the given piece of data. Data warehouses can contain any number of arbitrary data elements, such as metadata, structured in accordance with an extensible markup language (XML). Accordingly, document solution providers can save arbitrary metadata as XML with a given document and process this information using a given solution, having access to data after an event occurs, for example, when data is deleted or loaded into the data warehouse, and / or when the user opens / edits / saves a document.

Programmatic access can also be provided for data in their XML form during document editing. In accordance with one embodiment, a standard mechanism is provided that is known to developers of a solution by which you can access data and modify it programmatically when the document is open. Such programmatic access mimics standard XML interfaces. Programmatic access to data is provided through the application program interfaces to one or more editing client applications (for example, editing or document creation applications and / or to applications - added third-party solutions, etc.). Accordingly, many client applications can access and edit the same parts of the document data and any conflicting changes for this part of the data are allowed. "Side effects" of any given change can be performed (for example, in response to setting the company name to "Microsoft," it changes to standard "MSFT" characters). In addition, changes to the data and any associated side effects may be “interconnected” by the data store in such a way that canceling one or more changes will reverse all relevant changes. This helps to remove the development load from the solution itself in order to ensure that all changes are discarded when the user initiates the cancellation of the initial change on the document surface, for example, by clicking on the Undo command.

Standard XML Schemas (XSDs) can also be used to determine the content of any parts of custom XML data associated with document metadata, to ensure the validity of XML data applied to document data. Such schemas can be attached to any instance of the XML data stored in the document, and the data warehouse will prohibit any modification of the XML data, which will cause the XML structure (i.e., XML tags, as opposed to their contents) to become invalid. This helps ensure that the solution developer can attach a specific piece of XML metadata to the document and ensure that the XML data is structurally "consistent" with the associated schema, regardless of the data consumers (for example, add-ons) that use the data to modify it.

Consider now FIG. 2, in which document data 220 includes XML structure data and associated document data representing views of a surface or presentation level of a document. For example, document data 220 may include an XML structure (e.g., title tags, document body tags, completion tags) and associated surface view data (e.g. words, sentences, paragraphs) of a text editor document, spreadsheet document, slide presentation document, and etc.

A data warehouse 208 is a warehouse (repository) of document data designed to store one or more pieces of structured data associated with one or more data types associated with this document. Although only one data warehouse is shown in the drawing, more than one data warehouse can be used in practice. Metadata 1 225 (structured data element) may include XML structure data and associated data for the first part of the metadata associated with the document. For example, metadata 1 225 may include XML structure data (for example, date tags, title tags, etc.), which contains the name of the author of the document, the date the document was created, the date the document was last modified / saved, etc. Metadata 2,230 (structured data element) may include XML structure data (tags) and associated metadata representing the second part of the metadata associated with the document. As should be understood, metadata 1 and metadata 2 are presented for the purpose of example and do not limit the variety and many different types of data that may be stored in the data warehouse 208 in association with this document. For example, as described herein, arbitrary data can be structured and added to the document of one or more application programs in accordance with the wishes of solution providers or users who have access to document data.

A schema file 240, 245 can, if necessary, be added to each piece of data stored in the data warehouse 208, in order to dictate the syntax and validation rules associated with the Extensible Markup Language (XML) data for each piece of data 225, 230. Files XML schemas provide a way to describe and validate data in an XML environment. The schema file determines which XML markup data, including elements and attributes, is used to describe the content in the XML document, and the schema file determines the XML markup syntax, including whether each element is allowed, what types of content are allowed in within an element and which elements may appear within other elements. Using schema files ensures that the document (or, in this case, a separate piece of data) is structured in a consistent and predictable way. Schema files 240, 245 can be created by the user and are usually supported by an appropriate markup language such as XML.

Such a schematization of the document allows the data warehouse to provide the ability to "guarantee" the structural validity of the document by rejecting any change that violates the given schema file at the data warehouse level. According to an embodiment, the data validation module 208 uses the schema validation module 260 to validate the XML structure added to the given data part or the changes made to the given data part in accordance with the associated schema file. For example, if a document author or editor performs XML structural changes on a given piece of data, such as metadata 1, in which the editor adds or removes a given XML tag, the data warehouse 208 will use a schema validation module to validate XML structural changes according to the associated schema file to ensure the validity of the change. If the change is invalid, an error may be generated for the editor. It is understood that such control of the XML structure used for a given part of the data provides structural consistency and predictability, which are especially important for enabling the client application and the third party to interact with the associated data.

The data warehouse 208 provides one or more application programming interfaces (APIs) 270 that the client application 205 can access (e.g., text editor applications, spreadsheet applications, slide presentation presentations, etc.), as well as applications 210, 215, developed by a third party, through the object objects (OM, MO) of the respective applications 205, 210, 215. These APIs allow client applications and third-party applications to load any existing XML file into the data warehouse 208 of the specified document, providing assuming in this way that this data will now form part of the document and will move within this document for the duration of its existence (for example, when opening / editing / saving / renaming / etc.), or until this data will not be deleted from the data warehouse. In accordance with one embodiment, the data in the data warehouse will be available in their XML format, even when the source application for a given piece of data 225, 230 is closed or for some other reason is not available. Thus, access to a given part of the data 225, 230 can be done through API 270 by other applications (other than the source application). As described below, the APIs also allow client and third-party applications to make changes to the XML markup data applied to the data elements 225, 230.

Once the XML data 225, 230 is loaded into the data warehouse to associate with document 220, it can be manipulated as standard XML using data warehouse interfaces designed to provide methods similar to existing XML editing interfaces in order to use existing knowledge of the standard developer XML programming. This allows users to perform standard XML operations on XML data added to the data store for the document, for example, adding elements and attributes, deleting elements and attributes, changing the value of existing elements / attributes, and reading the value of any existing part of the associated XML tree. Using these standard XML operations, solutions can store structured complex (folded) metadata in a document that does not have any previous restrictions on the length / size of the data or data structure, which allows you to use this XML data warehouse for a significantly larger number of structural decisions than in prior art solutions. For example, for application 215, a third party may be able to post and highlight the document’s author names and document creation dates from multiple documents by reading the 1,225 metadata added to the data store 208 for each document. An example of a third-party application can be programmed at the application program level so that it will compile a list of document authors names and document creation dates for all documents created by a given organization. In accordance with embodiments of the present invention, a third-party application may use an XML structure applied to metadata 1 to efficiently find and retrieve the required data. For example, a third-party application may be written such that it parses the structure of the XML metadata file 1 to locate XML tags, such as <docauthor> and <doccreationdate>, to retrieve and use the data associated with these tags. It should be understood that the above is only one example of a variety of ways in which one or more applications can interact with structural data that is associated with a document through data storage 208.

In addition, data warehouse 208 provides any number of APIs 270 for any single piece of XML data 220, 225, 230 (also known as a storage element), to enable multiple applications 205, 210, 215 to work with the same piece of data. For example, several solutions, such as a client application (for example, a text editor application), and a third-party application solution (for example, the applications described above) can work with the same set of document properties (for example, properties contained in 2 file metadata 230). Using the data warehouse 208, each of these applications has separate access to the required XML data 230 through their own data warehouse API 270. This allows each application to communicate with the data through its own OM without the need for a complex solution for accessing multiple data consumers to the same piece of data.

In order to provide access for so many data applications 205, 210, 215 - data consumers to the same data, the data warehouse 208 notifies each of these applications when any part of the XML data is changed by another application, so that the specified application can respond to this change (both within itself, in accordance with its own process, and externally through other changes to the same data). When one application requests a change in a given data item, this request is automatically sent to all other applications, which allows other applications to determine how to respond and whether to respond to a requested change. In accordance with one embodiment, this is accomplished by allowing each application to register the ability to "listen" to any part of the XML data with which it has an interface, so that this application / program decision only accepts messages that correspond to its own logic. For example, one type of application 210 may wish to register listening for all changes made to given XML data in order to provide the ability to provide detailed business logic for a third-party solution, but another type of application 215 may wish to listen only for changes to one or two specific XML elements in within the same data, since its logic is not interested in changes to any other part of the XML data.

According to this embodiment, a plurality of applications 205, 210, 215 can access and edit the same piece of document data, and any conflicting changes to that piece of data are allowed. For example, “side effects” of any given change can be made when one change made by one application results in a change - a side effect of another application. For example, the first application 210 may obtain the task of extracting company names from one or more data elements 225, 230 associated with a given document, to translate these names into corresponding standard characters, if available, to compile a list of standard company symbols related to this document . If the second application 215 adds or changes the specified company name in the specified part of the metadata, for example, changes the company name from "Company ABC" to "Company XYZ," the first application can listen to this change to automatically update its list of standard symbols, to include these standard symbols in Company XYZ instead of Company ABC. In addition, such changes and any associated side effects may be interconnected by the data store 208 in such a way that canceling one or more changes will cancel all associated changes.

Figure 3 illustrates a system diagram representing the interaction between internal and external data consumers with XML data stores. As presented, system 300 includes a data store 302 including presentation layer 304, XML stores 1-N (306), each of which includes an error store and a cancellation store, a global change store 308, an optional global cancel store 310 , an internal broker 312, which is connected to external data consumers 1-N 314, and an external broker 316, which is connected to external data consumers 1-N 318.

Using a repository (s) 306 of XML data, documents have the ability to contain any number of arbitrary data elements (if only each of them corresponds to the standard XML syntax). Custom metadata can be stored in XML within the document, and this information can be automatically transferred in the forward and backward direction when the user opens / edits / saves the document.

As described above, programmatic access to this data is provided through the API, which can be used during document editing, providing a standard mechanism known to solution developers through which this information can be accessed and can be modified programmatically when this document is opened. In accordance with one embodiment, such programmatic access is designed to mimic standard XML interfaces. Using the API, data can be added / removed while an application, such as a text editor application, is running; data filling can be done within the storage element (a part within the data store); data can be manipulated using standard XML constructs; schemas can be associated with any arbitrary XML data in the data warehouse; schemes can be added / deleted / modified after their association with the data warehouse element; and XML changes can be represented as events for all listening clients. As illustrated, the API includes an external broker (intermediary) 316 that provides an interface for external data consumers 318, and an internal broker 312 that provides an interface for any internal data consumers 314 that interact with data storage 302.

Manipulations with data warehouse 302 can occur in real time. As described above, data stores 306 may contain one or more data types. For example, companies may have one data store that they use to store all the different types of data that they wish to store within the same data store, while another company may want to store data of other data types in other data stores.

Data consumers 318 can register for events that relate to activities related to data stores 306. For example, a data consumer may register to receive an event when any type of change is made to one or more data stores. Another data consumer may register for changes that occur to some element or set of elements in the data warehouse. Common events include loading the data store, adding to the data store, and deleting from the data store. When an event occurs, each registered data consumer can respond to this change, while the state of the data stores is uniformly maintained. Many times when a change occurs, the data consumer will not take any action. In other cases, the data consumer will perform some action (s) in response to the event. For example, a data consumer may make some other changes to the data warehouse in response to changes such as a change in name, or updating the headers in a document. a data consumer may also perform some other operations that do not affect the document. For example, if a symbol of a ticker (exchange machine) is inserted, the data consumer can search for data that is associated with this symbol of the ticker, even if all the data found cannot be displayed within the document at the presentation level. The data consumer may also reject the change. For example, if data consumer 1 receives a message about a change that cannot be accepted by him, that data consumer may return a flag to the broker indicating that the change has not been accepted. Whenever a change is not accepted, that change is canceled along with any side effects as if that change never happened. Each XML repository 306 can use its cancellation store to cancel the changes that it has fulfilled. Alternatively, the global rollback store 310 can be used to roll back changes made to the data stores. Suppose there are three data consumers who are interested in what is happening with respect to the properties of the document, with each of these data consumers registering to receive events related to the change in properties. When a change occurs, the data warehouse identifies each registered data consumer and informs each of them of the change in the specified order. Each data consumer, in turn, can perform some action in response to this change. If this change or any of the changes made by registered data consumers as a result of this change is not accepted by any one of the data consumers, all changes related to the original change will be canceled.

The external broker application programming interface level 316 provides access to the data store 302 for external data consumers 318 and allows third party customers to interact with the data store 302 in the same way as internal data consumers that are associated with the application interacting with the data store. For each of the 306 storage of XML data in the data store 302 contains a unique ID for identification. This allows you to find the storage 306 XML data.

At any time, the data consumer can add a schema that is used to validate the data in the data warehouse. Thus, if now any incoming third-party code tries to change the data, the first thing that the data warehouse does is determine whether such a change makes sense in accordance with the presented scheme. If the scheme is applied, the broker becomes the object of identification (check the correctness).

Data warehouses can also accept more than one item at a time. Providing data (XML) as one particular stream can provide the ability to meet the scheme in some situations. For example, suppose that in accordance with the attached scheme, if exchange data is present, they must contain at least two companies. If stock data are added one after the other, they may not be valid.

A single pass is used to validate the data. Instead of performing two passes, as a result of which it would be possible to make changes to the data warehouse, validation is performed before the data is transferred to the data warehouse. This helps prevent data consumers from introducing errors into the data warehouse.

4 and 5 illustrate the process of processing events related to the data warehouse. When reading the description of the procedures presented in this description, it should be understood that the logical operations in accordance with various embodiments are performed, (1) as a sequence of actions performed by a computer or program modules operating in a computer system, and / or (2) as mutually connected machine logical circuits or circuit modules of a computing system. Embodiment is a matter of choice that depends on the performance requirements of the computing system in which the invention is embodied. Accordingly, the logical operations illustrated and constituting the embodiments described herein are referred to differently as operations, structural devices, actions, or modules. These operations, structural devices, actions and modules can be embodied in the form of software, in the form of software and hardware, in the form of specialized digital logic circuits and in the form of any combination thereof.

Figure 4 illustrates the process of processing events that are associated with a data warehouse. In general, when a data warehouse receives a change request from a data consumer, the change is passed on to all registered data consumers to enable them to reject the change or request side effects (other XML changes) as a result of the change.

After the start of work, the process proceeds to operation 410, where the data consumer is registered with respect to any event (s) in the reception of which he is interested. These events may include adding data to the data warehouse, deleting data from the data warehouse, changing data in the data warehouse, etc. An event can be assigned to global changes or specific changes to elements that are stored in one or more data stores. For example, one data consumer may want to know when any change occurs, while another customer is only interested in changes to one particular value in the data warehouse.

Proceeding to decision operation 420, it is determined whether an event has occurred. An event refers to a data warehouse change. For example, as described above, the event may include the addition, deletion, or some other change to the data store. For example, a change may consist of adding a vertex (node) to the data store. When the event has not occurred, the process returns to decision operation 420. When an event has occurred, the process proceeds to operation 430.

In step 430 changes are transmitted to each of these customers, who have registered in respect of this change. In accordance with one embodiment, each data user is notified in a predetermined order. For example, the order may be based on the order of registration of data consumers.

Going to operation 440, a response is received from each of the data consumers who received the event notification. Each customer can accept or reject the change. The responses determine whether the change will be transferred to the data warehouse.

Proceeding to decision operation 450, it is determined whether one of the data consumers rejected the change in the data warehouse. When the change has been rejected by any of the data consumers, the process proceeds to step 460, where any changes that were made in response to the change are canceled, as if the change never occurred.

When all notified clients accept the change, the process proceeds to operation 470, where the change is verified if necessary, and then the process proceeds to operation 480, where the change is transferred to the corresponding data store.

The original data consumer that initiated the change then receives a notification that the change has been accepted (step 490). The process then proceeds to the final stage and returns to processing other actions.

5 illustrates an event processing process that includes side effects. Typically, when a data warehouse receives a change request from a data consumer, the change is passed on to all registered customers, providing them with the opportunity to reject the change or request side effects (other XML changes) as a result of the change. For example, a client may be informed of a change in one item in the data store, and as a result of the change, the data consumer makes another change in the data store. When a change is requested as a side effect, then the process is slightly different from the process shown in FIG. 4.

After the start of work, the process proceeds to operation 510, in which the client initiates a side effect change in relation to the data store as a result of the change that is currently being accepted or rejected.

Turning to step 520, the change side effect put in place, but do not perform. In other words, a side effect change is not performed immediately in the data warehouse. Based on this fact, alternatives for events include the following:

Force node operations (for example, adding, replacing) to return an empty value instead of the node and the document that makes up the request, not the action. Makes the result of a node operation consistent
Lack of execution
Remove from history the fact that if you want to manipulate a node, you should do it in his event AfterAdd Reflect the fact that the caller "requests" a change instead of making the change Makes the result of a node operation consistent
Lack of execution Performs the necessary changes for each caller, then discards them when the caller returns to its original state. Returns the active node to the caller Returns disconnected (it should be understood: a node not yet transferred) when changes are made as an event Returns the node before the change in all cases Supports separate DOM for OM client Returns the active node to the caller

Proceeding to decision operation 530, it is determined whether one of the data consumers rejected the original change in the data warehouse.

When the change has been rejected by any of the data consumers, the process proceeds to step 540, where any changes that were made in response to the change and any side changes that are queued are canceled as if no change had occurred.

When clients accept the original change, the process proceeds to operation 550, where the change is verified if necessary, and then the process proceeds to operation 560, where the original change is transferred to the corresponding data store.

The process then continues to operation 570, in which side effect changes are performed one at a time in the data warehouse. Each change of side effect can then be accepted or rejected by any of the registered clients. When any of the side effect changes is rejected, all changes that have been made are rejected, as if no changes were made at all.

The process then proceeds to the final stage and returns to processing other actions.

The following is an example of code segments that illustrate some of the common functions that are opened through the OM data warehouse:

The first example illustrates adding a stream to a data warehouse:

Dim oStream As CustomXMLPart

Set oStream = Document.XMLStreams.Add

oStream.Load ("c: \ specSolution.xml")

The second example illustrates the location of data in a warehouse.

Dim oStream As CustomXMLPart

Set oStream = Document.XMLStreams ("http://www.microsoft.com/office/12/specs")

The third example illustrates adding a subtree to the data warehouse.

oStream.SelectionNamespaces = oStream.SelectionNamespaces & "xmlns: s = 1http: //www.microsoft.com/office/12/specs" '

oStream.SelectSingleNode ("/ s: spec / s: specBody / s: issues").

AppendSubtree ("<s: issue> <s: issueBy /> <s: issueDate /> <s: issueDesc /> </ s: issue>")

In accordance with one embodiment, the following are exemplary functions that are associated with an API.

CustomXMLNode Events

Events can occur on CustomXMLNode, as well as once at the document level.

AfterInsert (NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: NewNode: a CustomXMLNode object corresponding to the newly added node in CustomXMLNode. Note: this node may have a child node (if the subtree has just been added to the document). InUndoRedo: Boolean returns TRUE if the node was added as part of the Undo / Redo action by the user, FALSE in other cases.

Such an event occurs whenever XML nodes are supposed to be added to the current document. If the operation involves adding a subtree to the XML document in CustomXMLNode, this event is fired once for the topmost node during the change. Such an event is fired once for each change declared to the data store, so the side effects of the change represented by this event also trigger the event.

AfterDelete (OldNode as CustomXMLNode, OldParentNode as CustomXMLNode, OldNextSibling as CustomXMLNode, InUndoRedo as Boolean)

Parameters: OldNode: a CustomXMLNode object corresponding to the node that has just been removed from CustomXMLPart. Note: No. 1: this vertex may have child vertices (if the subtree is removed from the document). Note: No. 2: This vertex will be a "disconnected" vertex in the sense that the request could be sent from the vertex, but could not be sent up - it probably exists alone (that is, it is a document element with the same OwnerStream) . OldParentNode: A CustomXMLNode object corresponding to the previous parent node for OldNode. OldNextSibling: A CustomXMLNode object corresponding to the previous next vertex of the same OldNode level. InUndoRedo: Boolean returns TRUE if the vertex was added by the user, as part of the Undo / Redo, FALSE action in other cases.

This event occurs whenever XML vertices (nodes) are removed from the current item in the data store. If the delete operation involves deleting the subtree of the XML document in CustomXMLPart, this event occurs once for the highest mutable vertex. Such an event occurs once for each change reported in the data store, so the side effects of the change represented by this event also trigger the event.

AfterReplace (OldNode as CustomXMLNode, NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: OldNode: a CustomXMLNode object corresponding to the vertex that has just been removed from CustomXMLPart. Note: No. 1: This vertex may have a child vertex (if the subtree is removed from the document). Note: No. 2: This vertex will be a “disconnected” vertex in that the request can be executed down from the vertex, but will not be passed up — it probably exists alone (that is, it is a document element with the same OwnerStream) . NewNode: A CustomXMLNode object corresponding to the just added vertex to CustomXMLPart. Note: This vertex may have a child vertex (if the subtree has just been added to the document). InUndoRedo: Boolean returns TRUE if the vertex was added by the user as part of the Undo / Redo, FALSE action in other cases.

This event occurs whenever XML vertices are replaced in the data store. If the replacement operation involves replacing the subtree of the XML document in CustomXMLPart, such an event occurs once for the highest vertex for which the change occurs. Such an event occurs once for each change declared for the data store, so the side effects of the change represented by this event also trigger the event.

CustomXMLParts (): Points for collecting all the data warehouse items available in a file that includes OLE document property streams and WSS property streams.

CustomXMLPrefixMappings: an object representing all the prefix conversions for the current part.

AddNamespace (Prefix as as String, NamespaceURI as String), as (Void)

Parameters: Prefix: String representing the prefix to add a prefix to the conversion list. NamespaceURI: String representing the namespace that is assigned to the newly added prefix.

Allows the developer to add a custom name / prefix space to use when this item is requested. If the prefix already exists in the administrator, it overwrites the value of the old prefix, unless the prefix is a prefix added / used inside the data warehouse, in which case an error is returned: "This prefix is already used and cannot be modified."

Count as Long: Returns the number of prefix conversions in the collection collection.

Item (Index as Long) as CustomXMLPrefixMapping

Parameters: Index: A Long value representing the index in the desired schema in the collection.

Returns the requested CustomXMLPrefixMapping from the collection. The default member of this object.

LookupNamespace (Prefix as String) as String

Parameters: Prefix: A String value that represents the prefix in the prefix conversion list. Allows the developer to obtain a namespace corresponding to the mentioned prefix. If no namespace is assigned to the requested prefix, "" is returned.

LookupPrefix (NamespaceURI as String) as String

Parameters: NamespaceURI: String value representing the namespace in the prefix conversion list;

Allows the developer to obtain a prefix corresponding to the namespace mentioned. If no prefix is assigned to the requested namespace, "" is returned. If there are many prefixes specified in the namespace, the administrator returns the first one that matches the provided namespace.

CustomXMLPrefixMapping: Object representing a prefix conversion.

Prefix as String: Returns the prefix for this prefix conversion.

NamespaceURI as String: Returns the namespace for this prefix conversion.

CustomXMLSchema: An object representing the schema that is part of the collection of the schema collection.

Delete as Void: Deletes this schema from the schema selection. If this is done for a schema in a collection that has already been verified or attached to the stream (active selection of varieties), then the error message appears: "This scheme cannot be deleted because the collection of the scheme is currently in use."

Location as String: Returns a string that represents the location of this scheme in the user's device.

NamespaceURI as String: Returns the target namespace of this schema, "" if none of them are XSD.

Reload as Void value: Reloads this scheme from disk, which proceeds to reattach a copy of this scheme to disk to: update its location (if SL has changed), and to make sure that it is still a valid scheme. If this is done for a schema in a collection that has already been checked or is tied to a thread (active selection of varieties), then an error message will be displayed: "This scheme cannot be reloaded because the selection of the scheme is currently being used."

CustomXMLSchemaCollection (): An object representing the collection (collection) of schemes (which are / will be attached to the stream).

Add ([NamespaceURI as String], [Alias as String], [FileName as String], [InstallForAllUsers as Boolean = False]) as CustomXMLSchema

Parameters: NamespaceURI: A String value representing the namespace of the schema to be added to the collection. If a schema exists in the schema library, it is obtained from it. Alias: String value representing the alias of the schema to be added to the collection. If an alias exists in SL, find it using this argument. FileName: A String value representing the location on the disk where the circuit can be found. If this parameter is specified, the scheme is added not only to the selection, but also added to the SL. InstallForAllUsers: A Boolean expression representing whether, in the case when a scheme is added to the scheme library, write the SL keys in HKLM (for all users) or HKCU (only for the current user). The default value is False (entry in HKCU).

This method allows the developer to add one or more schemas to the schema collection that is added to the stream in the data warehouse, as well as to the schema library. It can be activated with the following sets of parameters (in case of conflict, an attempt to use the parameters in the following order): [NamespaceURI], [Alias], FileName, [InstallForAHUsers] (adds a scheme to the library of the scheme if the scheme does not exist in this namespace) . NamespaceURI only (searches for XSD from the schema library). Alias only (searches for XSD from the schema library).

AddCollection (SchemaCollection as CustomXMLSchemas ()) as Void

Parameters: SchemaCollection: a CustomXMLSchemas () object that represents the selection (collection) of schemes that will be imported into the current selection.

Adds an existing collection to the current collection. If a namespace clashes during import (for example, if a.xsd is already associated with "fooNamespace" but the incoming collection has b.xsd for the same namespace), the incoming collection wins.

Count as Long: Returns the number of circuits in the collection.

Item (Index as Variant) as CustomXMLSchema

Parameters: Index: Variant value indicating the desired item in the collection. It can be any of: a String value representing the target namespace of the desired schema; or Long values representing the index of the desired schema in the collection.

Returns the requested CustomXMLSchema from the collection. The default member of this object.

NamespaceURI (Index as Long) as String

Parameters: Index: A Long value that represents the index of the schema in the collection.

Returns the target namespace of the referenced schema member.

Check as Boolean: Returns a Boolean value representing whether the circuits in the collection are checked or not. In addition, this also happens when Includes are moved for each schema in the collection and are added to the schemas that requested them.

CustomXMLParts (): A collection representing a collection of CustomXMLPart objects.

Add ([XML as String], [SchemaCollection as CustomXMLSchemaCollectionO]) as CustomXMLPart

Parameters: XML: an optional String value representing XML added to the newly created CustomXMLPart. SchemaCollection: an optional CustomDataSchemaCollection () object that represents a set of schemes to use when validating this stream.

Allows the user to add a new CustomXMLPart to the file. If the XML in the XML parameter is incorrectly generated, an error message is generated: "To add content to this stream, it must be valid, correctly formed XML." If the user provides a SchemaCollection: Check it (if it has not yet been verified). Run any MSXML that parses errors received back to the OM client, and it is not possible to add a stream. Check if the XML parameter can be loaded into the DOM. Otherwise, give an error message: "To add content to the stream, it must be valid correctly formed XML." Attach a schema selection to the DOM and try to validate this document. If it cannot be verified, issue an error message and run XML that parses the error received back to the OM client and does not add the stream to the collection.

If the user does NOT provide a SchemaCollection: check to see if the XML parameter can be loaded into the DOM. Otherwise, give an error message: "To add content to the stream, it must be valid correctly formed XML." View the list of namespaces represented in the XML file. Find circuits from SL and logically infer a selection of circuits for them. Try to verify the resulting selection of circuits. If it cannot be verified, still add the stream to the collection, but it will not be associated with any selection of schemes and, therefore, will not be checked. Add a selection of schemas to the DOM and try to check the current document. If it cannot be verified, throw an error and run XML that parses the error received back in the OM client and does not add the stream to the collection. If it cannot be verified, still add the stream to the collection, but it will not be associated with any selection of schemes and, therefore, will not be checked. Providing an empty SchemaCollection will be the explicit action that is taken and which means "never check this thread."

Count As Long: Returns the number of consumer data streams in the collection.

Item (Index as Variant) as CustomXMLPart

Parameters: Index: Variant, which can be one of the following two types: Long, representing the index of the desired CustomXMLPart in the collection; or a String value representing the root namespace specified by CustomXMLPart in the collection. If more than one part matches this root namespace, the first match will be returned in index order.

This is the default member of the CustomXMLParts object, and it returns the CustomXMLPart object corresponding to the requested object.

SelectByID (ID as String) as CustomXMLPart

Parameters: ID: String value containing the ID for the data store item to be returned from the collection.

Allows the developer to capture a specific item from the data store using its ID. If the storage item with this ID does not exist, Nothing is returned.

SelectByNamespace (NamespaceURI as String) as CustomXMLParts ()

Parameters: NamespaceURI: String representing the root namespace of the required items from the data warehouse collection.

Returns all data warehouse items whose root namespace matches the requested record. If there are no streams with such a root namespace, returns an empty CustomXMLParts () collection.

StreamAfterAdd (NewStream as CustomXMLPart)

Parameters: NewStream: a CustomXMLPart object containing the stream that has just been added.

This event occurs whenever a new stream is added to the data store. If multiple threads are added, events fire once for each new thread. If the stream was added with XML content (using the appropriate Add method), then this event will not be fired until the element is filled with content.

StreamBeforeDelete (OldStream as CustomXMLPart)

Parameters: OldStream: a CustomXMLPart object containing the stream that is about to be removed from the data store.

This event occurs whenever a stream is deleted from the data store. If multiple threads are deleted, events occur once for each thread that has been deleted. In addition, a flag is set for this stream, such as “about to be deleted” so that only read operations are valid with it (for example, querying vertices, checking values, etc.), but the write operation will not be performed and will be an error message was issued: "This operation cannot be performed for a thread that is about to be deleted."

CustomXMLPart: An object that represents a single XML stream in a data warehouse.

AddNode ([Name as String], [NamespaceURI as String], Parent As CustomXMLNode, [NextSibling as CustomXMLNode], [NodeType as msoCustomXMLNodeType], [NodeValue as String]) as Void

Parameters: Name: a String value that represents the base name of the vertex to be added to the XML DOM. Namespace: an optional String value that represents the namespace for the vertex to be added to the XML DOM. It is required to add vertices of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, ignoring the others. Parent: CustomXMLNode representing the vertex below which this vertex should be added. When adding an attribute, indicates the element to which the attribute is to be added. NextSibling: An optional CustomXMLNode representing the vertex that should become the next equal level vertex for the new vertex. If not specified, a vertex is added at the end of the child vertices of the parent vertex. Ignored to add type msoXMLNodeAttribute. If NextSibling is not a child vertex for the parent vertex, an error message is returned: "This vertex cannot be added because the next vertex of the same level is not a child for the parent vertex." NodeType: optional msoCustomXMLNodeType, which determines the type of vertex to be created. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String value that is used to set the vertex value for vertices where text is allowed. If no text is allowed at the vertex, this parameter is ignored.

A generic method for adding XML vertices to a data store element. A parent vertex is required and NodeType defaults to msoXMLNodeElement. If the resulting addition is structurally invalid, an error message is generated: "This operation cannot be performed because it could lead to a structurally invalid data stream." If the namespace is not in the collection of schema links, an error message is generated: "To add this element, you must first attach its schema to the data stream."

DocumentElement as CustomXMLNode

Get the root element of the stream. If the stream is empty, return Nothing.

Delete as empty data: Deletes the current CustomXMLPart from the data store. If the user tries to remove part of the basic properties, an error message is generated: "This part of the specialized XML is required for Office to function properly and cannot be deleted."

ID as String: Returns a string containing the GUID assigned to the current CustomXMLPart.

Load (FilePath as String) as Boolean

Parameters: FilePath: The String object corresponds to the file of the user's device (or network device, etc.) from which the XML for this CustomXMLPart must be loaded.

Allows the template author to populate CustomXMLPart from a previously existing file on his device. Returns TRUE if the load was successful, FALSE if not (which includes the case in which the structure is forced and the XML is structurally invalid, or the case when the XML was not valid and / or correctly formed). After loading the DOM, the error message "This DOM cannot be loaded twice" is generated.

LoadXML (XML as String) as Boolean

Parameters: XML: String object corresponding to the XML with which this CustomXMLPart should be loaded.

Allows the template author to populate CustomXMLPart from an XML string. Returns TRUE if the load was successful, FALSE if not (which includes the case in which the structure is forced and XML is structurally invalid, or the case in which the XML is not valid and / or correctly formed). After loading the DOM, the error message "This DOM cannot be loaded twice" is generated.

NamespaceURI as String: returns a string containing the full namespace URI for the root vertex of the current CustomXMLPart. If the stream is empty (created but no vertices added), returns "".

SchemaCollection as CustomXMLSchemaCollection (): Gets / sets the CustomXMLSchemaCollection () collection that represents the set of schemas attached to this stream. If the user presents a SchemaCollection: check its validity (if it has not yet been confirmed). Discard all analysis errors received back to the client and do not add to the stream; and attach the schema selection to the DOM and try to authenticate this document. If it is impossible to verify it, generate an error message and discard the analysis error received back to the client side and do not change the flowchart selection.

NamespaceManager as CustomXMLPrefixMappings ()

Gets the set of namespace prefix conversions used for the current CustomXMLPart. When a document is opened, it is automatically filled with the contents of the prefix transformations embedded in the data warehouse element, but the author of the template cannot edit / add / delete it. However, in accordance with this embodiment, changes to this parameter are not saved for the document.

SelectNodes (XPath as String) as CustomXMLNodes ()

Parameters: XPath: String value containing the XPath expression to evaluate against the DOM. The prefix mappings for this XPath are obtained from the associated namespace administrator. If XPath does not allow it, go through any generated error.

This method allows the developer to get back a set of vertices from the DOM.

SelectSingleNode (XPath as String) as CustomXMLNode

Parameters: XPath: String value containing the XPath expression to evaluate for the DOM. Prefix mappings for this XPath are obtained from the appropriate namespace administrator. If XPath does not provide resolution, a pass through any error is generated.

This method allows the developer to get back a single vertex from the DOM.

XML as String: Returns the XML representation of the current CustomXMLPart.

NodeAfterInsert (NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: NewNode: a CustomXMLNode object corresponding to the just added vertex in CustomXMLPart. Note: This vertex may have a child vertex (if the subtree has just been added to the document). InUndoRedo: Boolean returning TRUE if the vertex was added as part of the Undo / Redo action by the user, FALSE in other cases.

This event is fired whenever XML vertices are about to be added to the current document. If the add operation includes a subtree of the XML document being added to CustomXMLPart, this event is fired once for the top-most mutable vertex. This event is fired once for each change declared for the data store, so the side effects of the change represented by this event also trigger the event.

NodeAfterDelete (OldNode as CustomXMLNode, OldParentNode as CustomXMLNode, OldNextSibling as CustomXMLNode, InUndoRedo as Boolean).

Parameters: OldNode: a CustomXMLNode object corresponding to the vertex that has just been removed from CustomXMLPart. Note # 1: This vertex may have a child vertex (if the subtree is removed from the document). Note 2: This vertex will be a “disconnected” vertex at which the request can be sent down to this vertex, but does not go up: it looks as if it exists alone (that is, its document element with the same OwnerStream). OldParentNode: A CustomXMLNode object corresponding to the previous parent node of OldNode. OldNextSibling: A CustomXMLNode object corresponding to the previous next peer for OldNode. InUndoRedo: Boolean that returns TRUE if the vertex was added by the user as part of the Undo / Redo, FALSE action in other cases.

This event is raised whenever XML vertices are removed from the current item in the data store. If the delete operation spans the subtree of the XML document in CustomXMLPart, this event is fired once for the top-most mutable vertex. These events are fired once for each change declared in the data store, so the side effects of the change represented by this event also trigger the event.

NodeAfterReplace (OldNode as CustomXMLNode, NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: OldNode: CustomaXMLNode object corresponding to the vertex that has just been removed from CustomXMLPart. Note # 1: This vertex may have a child vertex (if the subtree is removed from the document). Note # 2: This vertex will be a “disconnected” vertex, in which the request can be sent down to the top, but cannot be sent up, it looks as if it exists alone (that is, it is a document element with the same OwnerStream). NewNode: The CustomXMLNode object corresponding to the just added vertex in CustomXMLPart. Note: This vertex may have a child vertex (if the subtree has just been added to the document). InUndoRedo: Boolean, returns TRUE if the vertex was added by the user as part of the Undo / Redo, FALSE action in other cases.

This event is fired whenever XML vertices are replaced in the data store. If the substitution operation involves a subtree of the XML document in CustomXMLPart, this event is fired once for the top-most mutable vertex. This event is fired once for each change declared in the data store, so the side effects of the change represented by this event are also triggered by this event.

CustomXMLNodes (): A collection representing a set of CustomXMLNode objects in the current document.

Count As Long: Returns the number of CustomXMLNodes in the collection.

Item (Index As Long) as CustomXMLNode

Parameters: Index: The Long value is the index of the desired CustomXMLNode in the collection.

It is the default element of the CustomXMLNodes object and returns a CustomXMLNode object corresponding to the requested element in the collection.

CustomXMLNode

AppendChildNode ([Name as String], [NamespaceURI as String], [NodeType as msoCustomXMLNodeType], [NodeValue as String]) as Void

Parameters: Name: an optional String value that represents the base name of the element to be added to the XML DOM. Namespace: an optional String value that represents the namespace of the element being added to the XML DOM. It is required to add vertices of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, ignoring the others. NodeType: optional msoCustomXMLNodeType, which determines the type of vertex to be created. If not specified, it is assumed to be msoCustomXMLNodeElement. Node Value: An optional String value that is used to set the vertex value for vertices that allow text. If the vertex does not allow text, this parameter is ignored.

Provides the developer with the ability to add a single vertex in the form of at least the last child vertex in the context of an element in the tree if the context vertex is of type msoXMLNodeElement. If not, then the method generates an error message: "You cannot attach a child to comments, processing instructions, or attributes." In addition, block any case in which the vertex to be added has an existing attribute: "an attribute with an existing name for the current element."

AppendChildSubtree (XML as String) as Void

Parameters: XML: String represents the subtree that is added to the XML DOM. This XML must be a well-formed XML document (including namespace declarations, one root vertex, etc.). If this is not the case, the error message is displayed: "Add the XML subtree to your document, it must contain valid correctly formed XML."

Allows the developer to add an existing, well-formed XML subtree as the last child subtree under the context element in the DOM if the context vertex is of type msoXMLNodeElement. If not, then this method leads to an error and the message: "You cannot attach a child subtree to the content, processing instructions or attributes."

Attributes as CustomXMLNodes (): Returns a CustomXMLNodes collection representing the attributes for the current element.

BaseName as String: represents the default CustomXMLNode element. It returns the base name of the vertex without a namespace prefix, if one exists in the DOM.

ChildNodes as CustomXMLNodes: Returns a CustomXMLNodes collection that contains all the elements that are children of the current vertex.

Delete as Void: Deletes the current vertex from the DOM XML (including in all its children, if any). If the resulting deletion is structurally invalid, an error message is displayed: "This operation cannot be performed because it may lead to a structurally invalid DOM."

FirstChild as CustomXMLNode; Returns a CustomXMLNode object corresponding to the first child of the current vertex. If the vertex does not have a child (or if it itself does not have the msoCustomXMLNodeElement type), nothing is returned.

HasChildNodes as Boolean: Returns a Boolean value that is True if the current vertex has vertices - children, otherwise False. Returns false when CustomXMLNode is not of type NodeType msoCustomXMLNodeElement.

InsertNodeBefore ([Name as String], [NamespaceURI as String], [NodeType as msoCustomXMLNodeType], [NodeValue as String], [NextSibling as CustomXMLNode]) as Void

Parameters: Name: A String value that represents the base name of the element to add to the XML DOM. Namespace: an optional String value that represents the namespace for the element being added to the XML DOM. Requires adding vertices of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, others are ignored. NodeType: optional msoCustomXMLNodeType type, which determines the type of vertex to be created. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String value that is used to set the vertex value for the vertices that provide text capability. If the vertex does not provide the ability to text, the parameter is ignored. NextSibling: An optional CustomXMLNode object that defines the vertex in front of which you want to add a new XML element to the tree.

Inserts a new child vertex into the tree at the specified location. If BeforeNode is not present, when adding a node of type msoCustomXMLNodeElement, msoCustomXMLNodeComment or msoCustomXMLNodeProcessingInstruction, the vertex is added to the end of the list. If it is added for type msoCustomXMLNodeAttribute, it is ignored. If NextSibling is not a child of the context node, then the method displays an error message: "This XML vertex cannot be added because the next equivalent element must be a child of the context element." If the resulting addition is structurally invalid (and the forced execution of the circuit is enabled), an error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM." It also blocks any case when a vertex that could be added already has an existing attribute: "an attribute with the same name already exists for the current element."

InsertSubtreeBefore (XML, as String, [NextSibling as CustomXMLNode]) as Void.

Parameters: XML: A String value representing the subtree added to the XML DOM. This XML must be a well-formed XML document (including namespace declarations, one root vertex, etc.). If this is not the case, the error message is displayed: “To add the XML subtree to your document, it must contain valid, well-formed XML.” NextSibling: an optional CustomXMLNode object that defines the vertex before a new XML element is added to the tree .

Inserts the specified XML subtree into the child vertex set at the referenced location. If NextSibling is not a child of the context node, the method displays the message: "This XML vertex cannot be added because the next sibling node must be a child of the context element." If the result obtained after adding is structurally invalid, an error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM."

LastChild as CustomXMLNode: Returns a CustomXMLNode object corresponding to the last child of the current vertex. If the vertex does not have children (or if it itself does not have the msoCustomXMLNodeElement type), nothing is returned.

NamespaceURI as String [read-only]

Returns the String value corresponding to the namespace of the current vertex. If the vertex is of type msoCustomXMLNodeComment msoCustomXMLNodeProcessingInstruction, "" is returned.

NextSibling as CustomXMLNode: Returns the next sibling vertex (element, comment, or machine instruction) of the current vertex. If the vertex is the last single-level vertex at its level, nothing is returned.

NodeType as msoCustomXMLNodeType: Returns the constant msoCustomXMLNodeType representing the type of the current vertex.

NodeValue as String: Gets / sets the text inside vertices containing only text (i.e., text vertices, comments, processing instructions, attributes). An error message is displayed for elements: "You cannot set NodeValue parameters for element vertices."

OwnerDocument as Variant: Returns a Document / Workbook / Presentation object representing the Word document associated with this vertex.

OwnerStream as CustomXMLPart: Returns a CustomXMLPart object representing the data store item associated with this vertex.

PreviousSibling as CustomXMLNode: Returns the previous sibling vertex (item, comment, or machine processing instruction) for the current vertex. If the vertex is the first single-level vertex at this level, nothing is returned.

ParentNode as CustomXMLNode: Returns the vertex - the parent element for the current vertex. If the vertex is at the root level, nothing is returned.

RemoveChild (Child as CustomXMLNode) as Void

Parameters: Child: a CustomXMLNode object that represents the child node for the context node to be deleted. If this vertex is not a child of the context vertex, an error message is displayed: "This vertex cannot be deleted because it is not a child of the current element."

Removes the specified child vertex from the stream. If the resulting DOM is structurally invalid, an error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM."

ReplaceChildNode (Name as String, [Namespace as String], [NodeType as msoCustomXMLNodeType], [NodeValue as String], OldNode as CustomXMLNode) as Void

Parameters: OldNode: CustomXMLNode representing the child node to be replaced. Name: String value that represents the base name of the element to add to the XML DOM. NameSpace: an optional String value that represents the namespace of the element being added to the XML DOM. It is required to add vertices of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, others are ignored. NodeType: optional msoCustomXMLNodeType type, which determines the type of vertex to be created. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String value that is used to set the vertex value for the vertices that provide text capability. If the vertex does not provide the ability to text, this parameter is ignored.

Removes the mentioned child vertex (and its subtree) from the stream and replaces it with the vertex specified at the same location. If OldNode is not a child of the context node, an error message is displayed: "OldNode must be a child of the current node." If the resulting replacement is structurally invalid, an error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM." In addition, any case is blocked when the vertex that could be added is an existing attribute: "an attribute with the same name already exists in the current element."

ReplaceChildSubtree (XML, as String, OldNode as CustomXMLNode) as Void

Parameters: OldNode: CustomXMLNode representing the child node to be replaced. XML: A String value representing the subtree to be added to the XML DOM. This XML must be a well-formed XML document (including declarations of namespace, single root vertex, etc.). If this is not the case, the error message is displayed: "To add an XML subtree to your document, it must contain valid, correctly formed XML."

Removes the specified vertex (and its subtree) from the stream and replaces it at the same location with the mentioned XML subtree. If OldNode is not a child of the context vertex, an error message is displayed: "OldNode must be a child of the current vertex." If the resulting replacement may be structurally invalid, the error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM."

SelectNodes (XPath as String) as CustomXMLNodes ()

Parameters: XPath: String value containing the XPath expression to evaluate for the DOM. The prefix conversion for this XPath is extracted from the NamespaceManager property. If XPath does not resolve the situation, it goes through any errors that occur (similar to the currently existing method applied to a Document object with embedded XML).

This method allows the developer to get back a set of vertices from the data store element.

SelectSingleNode (XPath as String) as CustomXMLNode ()

Parameters: XPath: String value containing the XPath expression to evaluate for the DOM. Prefix conversions for this XPath are extracted from the NamespaceManager property. If XPath does not resolve the situation, it passes through any errors that occur (similar to the method currently used for the Document object with embedded XML).

This method allows the developer to get back one vertex among the elements of the data warehouse.

Text as String: Gets / sets the text for the current vertex. Unlike MSXML, setting it for a vertex replaces the contents of this vertex with the specified string — for example, setting it to “test” on a non-leaf <foo> element, where the contents of foo are as follows:

<foo> Bar <baz> hello </baz> </foo>

It will not result in an error, but will result in a different internal message for the data store and external for the data store clients. If the resulting replacement is structurally invalid, the error message is displayed: "This operation cannot be performed because it could lead to a structurally invalid DOM."

XML as String: returns the unprocessed XML representation of the current vertex and its children (if any).

XPath as String: Returns a String value with canonicalized XPath for the current vertex. If the vertex is no longer in the DOM (has been deleted), an error message is displayed: "This vertex has been deleted from the corresponding part of the XML user)".

New Enums:

msoCustomXMLDataNodeType represents the types of XML vertices available; msoCustomXMLNodeAttribute represents the XML attribute vertex. msoCustomXMLNodeCData represents the top of CDATA. msoCustomXMLNodeComment represents the top of an XML comment. msoCustomXMLNodeDocument represents an XML document (/) vertex. msoCustomXMLNodeElement represents the top of an XML element. msoCustomXMLNodeProcessingInstruction represents the pinnacle of an XML processing instruction. msoCustomXMLNodeText represents a text vertex.

ReplaceChild (Child as CustomXMLNode, Name as String, [Namespace as String], [NodeType as String], [NodeValue as String]) as CustomXMLNode

Parameters: Child: a CustomXMLNode object that represents the child vertex of the context vertex to be deleted. If this vertex is not a child of the context vertex, an error message is displayed: "This vertex cannot be deleted because it is not a child of the current element." Name: String value that represents the base name of the element being added to the XML DOM. Namespace: an optional String value, which is the namespace of the elements added to the XML DOM. You need to add vertices of type msoXMLNodeElement or msoXMLNodeAttribute, others are ignored. NodeType: an optional msoXMLNodeType type that defines the type of vertex to create. If it is not specified, it is assumed to be msoXMLNodeElement. Node Value: An optional String value that is used to set the vertex value for vertices that allow text. If the vertex does not provide the ability to text, this parameter is ignored.

Removes the mentioned child vertex (and its subtree) from the stream and replaces it with the vertex specified at the same location. If the result of the deletion results in an invalid structure (and the enforcement scheme is turned on), an error message is displayed: "This operation could not be performed because it could lead to a structurally invalid DOM."

XMLNamespace: An object representing a single unique namespace in the Schema Library.

AttachToCustomXMLPart (CustomXMLPart as Variant) as Void

Parameters: CustomXMLPart: Variant, which can be either a CustomXMLPart object for the required stream, or an index of this stream in the CustomXMLParts collection.

Attach a schema for this XML namespace for the given CustomXMLPart.

XMLSchemaReference: an object representing a single unique namespace referenced in the current document,

Delete () as Void: Deletes the namespace, as well as all elements in this namespace, from CustomXMLPart. However, in this case, the data warehouse may reject this operation, because the forced execution of the structural diagram is enabled, and the removal of these elements will lead to a structurally invalid DOM. In this case, the error message is displayed: "This operation cannot be performed because the forced execution scheme is enabled due to the fact that the received stream would be structurally invalid."

Add (Name as String, Namespace as String, [Parent as CustomXMLNode], [NextSibling as CustomXMLDataNode], [NodeType as msoXMLNodeType], [NodeValue as String]) as CustomXMLNode

Parameters: Name: A String value that represents the base name of the element to add to the XML DOM. Namespace: an optional String value that represents the namespace of the element that is added to the XML DOM. It is required to add vertices of the msoXMLNodeElement or msoXMLNodeAttribute types, others are ignored. Parent: Optional CustomXMLNode representing the vertex below which this vertex should be added. If it is revoked, the CustomXMLNodes collection is returned by the Attributes property and then it is assumed that it represents the parent node for the attributes. If it is called in any other case, then this parameter indicates or returns an error: "You must specify the parent vertex to add this vertex to your document." NextSibling: Optional CustomXMLNode representing the vertex, which should be the next sibling vertex for the new vertex. If not specified, this vertex is added at the end of the child vertex for the parent vertex. Ignored to add type msoXMLNodeAttribute. If NextSibling is not a child or parent vertex, an error message is returned: "This vertex cannot be added because the next sibling vertex is not a child or parent vertex." NodeType: optional msoXMLNodeType, which determines the type of vertex to be created. If it is not specified, it is assumed that it is an msoXMLNodeElement, unless the Attributes property is revoked, then it is assumed that it is an msoXMLNodeAttribute. NodeValue: An optional String value that is used to set the vertex value for vertices that allow text. If the vertex does not provide the ability to text, this parameter is ignored.

A general method of adding XML vertices to a data warehouse item. If its object returned by the Attributes property is revoked from CustomXMLNodes, then Parent has the default value for the parent vertex, and NodeType has the default value for msoXMLNodeAttribute. In all other cases, Parent is required, and NodeType is set to msoXMLNodeElement by default. If the resulting addition is structurally invalid (and the enforcement scheme is enabled), an error message is displayed: "This operation cannot be performed while the enforcement scheme is enabled, because it could lead to a structurally invalid data stream." If the namespace is not contained in the selection of schema links, an error occurs and the message: "To add this element, you must first attach its schema to the data stream."

CustomDataXMLSchemaReferences (): A collection representing all the unique namespaces identified in CustomXMLPart. Note: By default, it is populated with entries for each namespace declared in the XML file.

Add ([NamespaceURI as String], [Alias as String], [FileName as String], [InstallForAllUsers as Boolean = False]) as XMLSchemaReference

Parameters: NamespaceURI: String value containing the namespace defined by the schema to add the schema collection. Alias: String value containing an alias to write when this schema is added to the schema library. FileName: String value containing the path to the schema to be added to the schema library. InstallForAllUsers: a boolean value that determines whether to add Schema Library keys to HKCU (default) or HKLM

This method adds a link to the schema. To this end, add the appropriate namespace declaration to the root element of CustomXMLPart, if it is not already defined in the file. At the time of opening, all declared namespaces are used to populate this collection.

EnforceStructure as Boolean: Gets and sets a Boolean value that matches whether to force the structural validity of the data store to be associated with the associated CustomXMLPart in accordance with its scheme. If the user tries to set this property to TRUE while the content of CustomXMLPart is invalid, an error message is returned: "forced execution of the circuit cannot be enabled while the content of this data stream is structurally invalid".

Count as Long: Returns the number of namespaces that are currently accessed in this CustomXMLPart.

Item (Index as Variant) as XMLSchemaReference

Parameters: Index: a Variant value, which can be one of the following two types: Long, representing the index of the desired CustomDataXMLSchemaReference in the collection; and a String value representing the namespace of the required CustomDataXMLSchemaReference in the collection.

It is the default element of the CustomDataXMLSchemaReferences object and returns an XMLSchemaReference object corresponding to the requested object.

Validate () as Void: This method checks the entire stream for all schemes in the CustomDataXMLSchemaReferences collection. Errors are reported on individual vertices (see the ValidationStatus property) /

CustomXMLNode

NodeAfterInsert (NewCustomXMLNode as CustomXMLNode, InUndoRedo as Boolean).

Parameters: NewCustomXMLNode: a CustomXMLNode object corresponding to the top of the newly added CustomXMLPart. Note: This vertex may have a child vertex (if the subtree has just been added to the document). InUndoRedo: Boolean returning TRUE if the vertex was added as part of the Undo / Redo action by the user, FALSE in other cases.

This event occurs whenever XML vertices are supposed to be added to the current document. If the add operation involves adding the subtree of the XML document to CustomXMLPart, this event occurs once for the topmost changing vertex. This event occurs once for each change declared to the data store, so the side effects of the change represented by this event also trigger the event.

NodeBeforeDelete (OldCustomXMLNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: OldCustomXMLNode: a CustomXMLNode object corresponding to the vertex to be removed from CustomXMLPart. Note: This vertex may have a child vertex (if the subtree is removed from the document). InUndoRedo: a Boolean value that returns TRUE if the vertex was added by the user as part of the Undo / Redo action, in other cases FALSE.

This event occurs whenever XML vertices are removed from the current item in the data warehouse. If the delete operation involves a subtree of the XML document in CustomXMLPart, this event occurs once for the top-most mutable vertex. Such an event occurs once for each change declared in the data store, therefore the side effects of the change represented by this event also trigger the event. If the event handler tries to modify anything that might be under this vertex, an error occurs and an error message is displayed: "This change is not allowed because it is assumed that this vertex will be deleted."

The above description, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention is presented in the appended claims.

Claims (16)

1. A computer-readable medium having computer-executable instructions for managing data associated with computer-generated documents, by the steps of:
store the structured data elements that are associated with the document in a data warehouse that is separate from the document, and the structured data elements are presented in an extensible markup language (XML),
formatting structured data such that an application programming interface (API) is provided for a plurality of data consuming applications to provide programmatic access for data consuming applications to structured data elements; moreover, the execution of the API provides the ability to access structured data elements within the data warehouse when the document is open and when the document is closed, while the API, which allows programmatic access to structured data elements by data consuming applications, comprises the step of allowing multiple applications consuming data, access the same structured data element at the same time,
register to perform notification of changes through applications consuming data,
determine when a change is made to one of the elements of structured data using the API; and when the change is made, registered applications consuming data are notified of this change;
in response to the notification of the change, a side change is queued by one of the data consuming applications, this side change being generated based on data related to the notified change,
Notify registered applications that consume data of a side change. 2. The computer-readable storage medium according to claim 1, further comprising the step of canceling the changes when one of the registered data consuming applications rejects the change and transmitting the changes to the data store when each of the registered data consuming applications accepts change. 3. The computer-readable storage medium according to claim 2, further comprising the step of using the API to associate the structured data element with an XML schema file, which is used to validate the structured data element before the change is transferred to the data warehouse. 4. The computer-readable storage medium according to claim 1, wherein the API provides a registration function for receiving a notification for notification of changes in relation to at least one of: changes to the data store and changes to one or more structured data elements; moreover, the change may include the removal, addition and modification of at least one of the data warehouse and the structured data element. 5. The computer-readable storage medium according to claim 4, wherein the API provides an interface for adding vertices to the data store; Removing vertices from the data warehouse and replacing the top in the data warehouse. 6. The computer-readable storage medium according to claim 4, wherein the API provides an interface for filling the data store using an existing file; and populating the data warehouse using an XML string. 7. The computer-readable storage medium according to claim 4, wherein the API provides an interface for adding a namespace; namespace search; add schema; delete schema; and reloading the circuit. 8. The computer-readable storage medium according to claim 4, wherein the API provides an interface for adding a stream; stream removal; add subtree; delete subtree; getting the next sibling vertex for the current vertex; and obtaining the previous sibling vertex for the current vertex receiving the vertex type. 9. The computer-readable storage medium according to claim 4, wherein the API provides an interface for obtaining vertex values; and enforcing the structure. 10. A computer-implemented method for managing data associated with documents generated by a computer, comprising the steps of:
store structured data elements that are associated with documents using data warehouses; wherein the structured data element is structured in accordance with an extensible markup language (XML); and
format structured data such that an application programming interface (API) is provided for data consuming applications that provide programmatic access to documents and structured data elements contained in data warehouses; and
perform this API to access structured data elements located in the data warehouse while the document is being edited and when the document is closed, so that structured data is associated with documents and functions as metadata describing the characteristics of the document; and while the application consuming data when it is registered, receives a notification of a change made in the data warehouse,
initiate a change in one of the data stores using the API,
transmit a notification to the second registered application consuming data about the change,
in response to the notification in the second registered application consuming data, they queue a side change,
determining when the response from the second registered application consuming the data is a deviation, and when the response is a deviation, cancel the change and collateral change,
determining when the first and second registered data consuming application accepts the change and side change, and when the first and second registered data consuming application accepts the change and the side change, it is not necessary to verify the change and side change using the XML schema, which is provided by one of the applications that consume data using the API,
transmit the change and side change to one or more data stores. 11. The computer-executed method of claim 10, wherein the use of the API further comprises the steps of:
provide a programming interface to get the value for the top; adding tops; top removal; vertex movement;
add schema; delete schema; reloading the circuit; Add a namespace and delete a namespace. 12. A data management system associated with computer-generated documents, comprising:
CPU,
computer-readable media connected to the processor,
applications consuming data capable of being executed in a processor;
document data storage, which is arranged to save documents on computer-readable media; and
a data warehouse connected to data consuming applications configured to store structured data elements that are associated with one or more documents; wherein the data stores include: XML data stores; API broker configured to interact with data consuming applications; a change repository that is configured to store changes that are associated with a change that is made with respect to the structured data elements; and cancel the store, which is arranged to cancel any changes made as a result of changes which have been made in relation to the structured data element; at the same time, the API broker provides an application programming interface (API) that allows you to provide programmatic access to documents and to the structured data element contained in data warehouses; and while the data consuming application is configured to execute the API to access structured data elements in the data stores, both when the document is open and when the document is closed, so that the API provides programmatic communication with the application, consuming data to associate items in the data store with the document, and the data consuming application is also configured to queue a side change when the item in the data store is changed. 13. The system of claim 12, wherein the data warehouse is further configured to:
receiving change markup data of an extensible markup language (XML) applied to the structured data element;
reading the XML schema file associated with the structured data element to which changes to the XML markup data are directed;
determining whether the markup XML data is valid according to the read XML schema file; and
prohibiting changes to the XML markup data if the change to the XML markup data is not valid in accordance with the read XML schema file; and transfer changes in one or more XML storage when the XML markup data change is valid according to the read XML schema file. 14. The system of claim 12, wherein each of the XML data stores contains a cancellation store and a change store. 15. The system of claim 12, wherein the API provides an interface for adding vertices to the data store; Removing vertices from the data warehouse vertex replacements in the data warehouse; and getting the value from the data store. 16. The system of claim 15, wherein the API provides an interface for adding a circuit; delete schema; and reloading the circuit.

Images