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

Abstract

Programmable modes of interacting with data repositories within documents allow for real-time interaction. Data for structuring information associated with the document, such as document metadata, is maintained in a data store, where relationships between different data are maintained at a different location than the surface level view of the document. The data store exposes an interface to various data within the data store to allow different applications to access and process one or more of the data. These data can be structured according to markup languages such as Extensible Markup Language (XML), and the XML schema allows each data schema to validate the structure applied to the data based on the XML schema associated with the given data. May be associated with

XML Schema, Markup Language, Data Store, XSD

Description

PROGRAMMABILITY FOR XML DATA STORE FOR DOCUMENTS}

Computer users have become accustomed to easy-to-use software applications that help them write, calculate, organize, prepare presentations, send and receive e-mails, compose, and so on. . For example, word processing applications allow a user to prepare a variety of useful documents. Spreadsheet applications allow users to enter, manipulate, and organize data. Slide presentation applications allow a user to create a variety of slide presentations including text, pictures, data or other useful objects.

However, documents generated by such applications (eg word processing documents, spreadsheets, slide presentation documents) have limited ability to store / transmit the contents of arbitrary metadata required by the context of the document. . For example, a solution written on a word processing document may contain workflow data describing various states of the document, such as previous workflow approval data (date, time, name), current approval status, future before completion. May need to save the workflow status, document author's name and office address, document changes, and so forth. The option to store this information is limited primarily to the use of existing custom object linking and embedding (OLE) document attributes with document variables or restrictions. For example, hierarchical data may not be stored, character length is limited, and so forth. The properties for these methods are stored in a single store, for example, the OLE property store, which means that there is a potential for conflicting properties. In addition, these stored attributes are not subject to data verification. It is difficult for users of such applications and related documents to store arbitrary data with the documents (which is a common requirement of many users).

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

One or more data repositories are maintained separately from the basic presentation store within a document to store, associate with, and enable use of any data associated with the computer-generated document. Data structuring information associated with the document, such as document metadata, is maintained in the data store, where relationships between different data are maintained. This data store exposes an application programming interface (API) to various data in the data store to allow different applications to access and process one or more of the data.

These data can be structured according to markup languages such as XML (Extensible Markup Language). An XML schema 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 data. Programmatic access to data in XML form is provided while the document is being edited. Multiple client applications can access and edit the same document data, and any conflicting changes to the given data are resolved. Standard XML schema (XSD) can also be used to define the content of any of the custom XML data associated with document metadata to ensure that the XML data applied to the document data is valid.

1 illustrates an exemplary computing architecture of a computer.

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

3 is a system diagram illustrating interaction between internal and external data consumers having an XML data store.

4 illustrates a process for handling events associated with a data store.

5 illustrates a process for handling an event that includes an incidental effect, in accordance with aspects of the present invention.

In the following, various aspects of the present invention will be described with reference to the drawings, wherein like reference numerals refer to like elements. In particular, FIG. 1 and corresponding description are intended to provide a brief, general description of a suitable computing environment in which embodiments of the invention may be implemented.

Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Other computer system configurations may also be used, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Distributed computing environments may also be used in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Referring to FIG. 1, one exemplary system implementing the present invention includes a computing device, such as computing device 100. In a very basic configuration, computing device 100 typically includes at least one processing device 102 and system memory 104. Depending on the exact configuration and type of computing device, system memory 104 may be volatile (RAM, etc.), nonvolatile (ROM, flash memory, etc.) or some combination of the two. System memory 104 typically includes an operating system 105 and one or more applications 106, and may include program data 107. In one embodiment, the application 106 may include a word processor application 120. This basic configuration is shown in FIG. 1 by the components in dashed line 108.

Computing device 100 may have additional features or functionality. For example, computing device 100 may include additional data storage devices (removable and / or non-removable), such as, for example, magnetic disks, optical disks, or tapes. Such additional storage devices are shown in FIG. 1 as removable storage device 109 and non-removable storage device 110. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in 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 may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROMs, digital versatile disks or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or And any other medium that can be accessed by computing device 100 and used to store desired information. Any such computer storage media may be part of the device 100. Computing device 100 may also have input device (s) 112 such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output device (s) 114 such as displays, speakers, printers, and the like may also be included. These devices are known in the art and need not be discussed in detail here.

Computing device 100 may also include a communication connection 116 that enables the device to communicate with other computing devices 118, such as through a network. Communication connection 116 is one example of communication media. Communication media can typically be implemented by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier or other transmission mechanism, and includes any information delivery media. The term " modulated data signal " refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term 'computer readable medium', as used herein, includes both storage media and communication media.

A number of program modules and data files, such as operating system 105, suitable for controlling the operation of a networked personal computer, such as the WINDOWS operating system of MICROSOFT Corporation, Redmond, WA, may include system memory 104 of computing device 100. ) Can be stored. System memory 104 may also store one or more program modules, such as word processor application 120 and others described below. The word processor application 120 operates to provide functionality for creating, editing, and processing electronic documents.

According to one embodiment of the invention, the word processor application 120 includes a WORD program from MICROSOFT Corporation. However, it will be appreciated that other manufacturers' word processor application programs may be used. Examples of word processing applications are merely examples, and do not limit other types of applications that can generate and process documents. For example, other application programs 106 (spreadsheet application programs, database application programs, slide presentation application programs, drawings, etc.) that can handle various types of content (e.g., text, images, drawings, etc.). Or computer-assisted application programs, etc.) is equally applicable. Exemplary application program 106 for generating and processing various different types of documents includes OFFICE from MICROSOFT Corporation.

Embodiments may be implemented as computer processes, computing systems, or articles of manufacture such as computer program products or computer readable media. A computer program product may be a computer storage medium that is readable by a computer system and encodes a computer program in instructions that execute a computer process. The computer program product may also be a signal propagated onto a carrier that is readable by the computing system and encodes a computer program of instructions that executes the computer process.

Throughout the specification and claims, the following terms have the associated meanings herein, unless the context of the term says otherwise.

The term "data" refers to document surface level or presentation level information, such as words, sentences, paragraphs, and the like, as well as supplemental information, such as metadata conveyed by, referenced by, or used by a word processing document. Say. This information is often large and may not be exposed on the presentation layer of the document.

The term "presentation" refers to the visible part of a document such as text and layout that appears when the document is printed.

The term "tag" refers to a character inserted into a document that separates elements within an XML document. Each element typically contains two tags, a start tag and an end tag. It can have an empty element (no content), in which case one tag is allowed.

The term "markup language", or "ML", refers to a language for special code within a document that specifies how portions of the document should be interpreted by the application. In a word processor file, the markup language specifies what format or layout the text should be.

The term "element" refers to the basic unit of an XML document. This element can contain attributes for XML documents, other elements, text, and other content areas.

The term "building block" refers to a possibly labeled area within a document that serves as a container for a particular type of content entered by a user.

The term "data binding, data mapping, and data field" refers to an attribute for a building block that determines the XPath to the XML DOM stored in the document if the content of the building block should be stored.

XML content between tags is considered as the "child" (or descendant) of the element. Thus, other elements embedded within the content of an element are referred to as "child elements" or "child nodes" or elements. Text embedded directly within the content of an element is considered an "child text node" of the element. The child element and the text within the element together make up the "content" of that element.

The term "attribute" refers to additional attributes that are set to specific values and associated with an element. An element can have any number of attribute settings (including none) associated with it. Attributes are used to associate additional information with elements that contain additional elements or that are not treated as text nodes.

"XPath" is an operator that uses a pattern representation to identify nodes in an XML document. The XPath pattern is a slash-separated list of child element names that describe the path through the XML document. This pattern "selects" elements that match the path.

The term “XML data store or data store” is a word processor document, spreadsheet document, slide presentation document that provides access for storing and modifying data (eg, in XML format) stored in a document while the file is open. Container within a document, and so on. Further definitions of the XML data store are provided below in connection with FIG. 2.

2 is a block diagram illustrating a relationship between one or more client applications and one or more data stores and the contents of the data store (s). Generally described, one or more data repositories are maintained separate from the basic presentation store within a document to store, associate with, and permit use of any data associated with the computer-generated document. Data structuring information associated with a document, such as document metadata, is maintained in a data store, where relationships between different data are maintained. This data store exposes an application programming interface (API) to various data in the data store to enable different applications to access and process one or more of the data. As used herein, the terms “data consumer”, “application” and “process” may be used interchangeably unless the context clearly dictates otherwise.

The data may be structured according to a markup language such as XML (Extensible Markup Language). An XML schema can be associated with each data, and the data store can validate the XML structure applied to the data based on the XML schema associated with the given data. The data store may include any number of arbitrary data items, eg metadata, structured according to XML. As such, the document solution provider can store arbitrary metadata as XML with a given document, when the data is removed or loaded into the data store, and / or when the document is opened / edited / saved by the user, etc. The information is processed by a given solution that accesses the data upon the occurrence of an event.

Programmatic access to data in XML form can also be provided while the document is being edited. According to one embodiment, a standard mechanism familiar to the solution developer is provided, through which data can be accessed and modified programmatically while the document is open. This programmatic access mimics the standard XML interface. Programmatic access to data is provided to one or more editing client applications (eg, document editing or generation applications and / or third party application add-in solutions, etc.) via an application programming interface. As such, multiple client applications can access and edit the same document data, and any conflicting changes to the given data are resolved. A "side effect" may occur for any given change (eg, changing the stock symbol to "MSFT" in response to setting the company name to "Microsoft"). In addition, changes to the data and any associated side effects can be "bulled" by the data store such that undoing one or more changes invalidates all related changes. This helps remove the development burden from the solution itself to ensure that the user invalidates all changes when initiating the first change from the document surface, for example by pressing the Undo command. .

The standard XML Schema (XSD) can also be used to define the content of any of the custom XML data associated with document metadata to ensure that the XML data applied to the document data is valid. These schemas can be attached to any instance of XML data stored in the document, and the data store does not allow any changes to the XML data, resulting in the XML structure of the data (ie, XML tags rather than its contents). It is not invalidated. This ensures that solution developers can attach specific XML metadata to documents and that XML data continues to be associated with whatever data consumer (eg, add-in) is used to modify that data. It helps to ensure that the schema is "correct" structurally.

Referring now to FIG. 2, document data 220 includes XML structured data and associated document data that provides a surface or presentation level view of the document. For example, document data 220 may contain XML structures (eg, heading tags, body tags, conclusion tags) and associated surface view data such as word processing documents, spreadsheet documents, slide presentation documents, and the like. data) (eg, words, sentences, paragraphs).

Data store 208 is a document data store that stores one or more structured data associated with one or more types of data associated with a given document. Although only one data store is shown, more than one data store may be used. Metadata 1 225 (structured data item) may include XML structured data and associated data for first metadata associated with a document. For example, metadata 1 225 contains XML structured data (eg, date tag, name tag, etc.) that lists the author of the document, document creation date, document last changed / save date, etc. can do. Metadata 2 230 (structured data item) may include XML structured data (tags) and associated metadata representing second metadata associated with the document. As will be appreciated, metadata 1 and metadata 2 are for illustrative purposes and do not limit the type and number of different types of data that can be maintained in data store 208 in connection with a given document. For example, as described herein, arbitrary data can be structured and added to a document by one or more software applications as desired by a solution provider or user accessing the document data.

Schema files 240 and 245 may optionally be attached to each data stored in data store 208 to enforce syntax and validation rules associated with the XML data applied to each data 225 and 230. XML schema files provide a way to describe and validate data in an XML environment. The schema file describes which XML markup data, including attributes and elements, are used to describe the content in the XML document. The schema file describes where each element is allowed and what type of content within the element. Define XML markup syntax, including what is allowed and which elements can appear within other elements. The use of a schema file ensures that the document (or in this case individual data) is structured in a consistent and predictable manner. Schema files 240 and 245 can be generated by a user and generally supported by an associated markup language such as XML.

This schematization of the document allows the data store to provide the ability to "guarantee" the structural validity of the document by rejecting any changes that violate a given schema file at the data store level. According to one embodiment, the data store 208 utilizes a schema validation module 260 that verifies the XML structure added to a given data or changes made to it in contrast to the associated schema file. For example, if a document creator or editor makes XML structural changes to a given data, for example metadata 1, where the editor adds or removes a given XML tag, the data store 208 is associated with the associated schema file. In contrast, the schema validation module is used to check the XML structural changes to ensure the validity of the changes. If the change is invalid, an error may be raised and sent to the editor. As will be appreciated, this control of the XML structure applied to a given data takes into account structural consistency and predictability, which is particularly important to allow clients and third party applications to interact with the associated data.

The data store 208 is not limited to the client application 205 (eg, word processing application, spreadsheet application, slide presentation application, etc.) as well as the respective application 205 by the third party applications 210, 215. One or more application programming interfaces (APIs) 270 that can be accessed through the object model (OM) of 210, 215. These APIs allow client applications and third party applications to load any existing XML file into the data store 208 of a given document, so that the data is now part of the document and for its lifetime (eg , Open / edit / save / rename / etc.), I.e., move through the document until the data is deleted from the data store. According to one embodiment, the data in the data store is available in its XML format even when the source application for a given data 225, 230 is closed or otherwise not available. That is, given data 225, 230 may be accessed via API 270 by other applications (other than the source application). As described below, the API also allows client and third party applications to make changes to the XML markup data applied to the data items 225, 230.

Once the XML data 225, 230 is loaded into the data store to associate with the document 220, it is designed to provide methods similar to existing XML editing interfaces to take advantage of the developer's existing knowledge of XML programming standards. Can be treated as standard XML using the repository interface. This allows the user to add standard XML behavior (adding elements and attributes, removing elements and attributes, changing the values of existing elements / attributes, and associated XML trees) for XML data added to the document's data store. Reads the value of any existing part of. Using this XML standard behavior, the solution can store complex metadata structured with documents that do not accept any of the previous limitations on the length / size of the data or the structure of the data, which is considerably more structured than the previous solution. It is possible to use this XML data store for an existing solution. For example, third-party application 215 may be used to locate and extract document author names and document creation dates from multiple documents by reading metadata 1 225 added to data repository 208 for each document. This can be written. This example third party application may be an application programmed to create a list of document author names and document creation dates for all documents generated by a given organization. According to embodiments of the present invention, a third party application may use an XML structure applied to metadata 1 to efficiently find and extract desired data. For example, a third-party application can be written to parse the XML structure of the metadata 1 file, find XML tags such as <docauthor> and <doccreationdate>, and obtain and use the data associated with those tags. As will be appreciated, the above is only one example of the many ways in which one or more applications can interact with the structured data associated with the document through the data store 208.

In addition, the data store 208 may include any individual XML data 220, 225, 230 (store item) to allow multiple applications 205, 210, 215 to work with the same data. ), Any number of API interfaces 270 may be provided. For example, some solutions, such as client applications (e.g., word processing applications) and third party application solutions (e.g., the applications described above), share the same set of document attributes (e.g., metadata 2 ( 230) you can work with the properties contained in the file. Using the data store 208, each of these applications allows each application to communicate with the data through its own OM without having to deal with the complexity of having multiple data consumers accessing the same data. Receive individual access to the desired XML data 230 via its own data store API interface 270.

 In order to allow these multiple data consuming applications 205, 210, 215 to access the same data, the data store 208 notifies each of these applications when any portion of the XML data is changed by another application. This allows a given application to respond to that change (by internally changing its own process and externally to another change to the same data). When an application requests a change for a given data item, the request is automatically sent to all other applications to allow other applications to determine how or whether to respond to the requested change. According to one embodiment, this means that each application has an arbitrary portion of the XML data (this application has an interface to it) so that a given application solution / program receives only those messages related to its own logic. This is accomplished by allowing you to register to "listen". For example, one type of application 210 may wish to register to listen for all changes made to a given XML data to provide detailed business logic capabilities to a third party solution, but another type of application. 215 may only want to listen for changes to one or two specific XML elements in the same data, because its logic does not care about changes to any other portion of the XML data.

According to this embodiment, multiple applications 205, 210, and 215 can access and edit the same document data, and any conflicting changes to the given data are resolved. For example, a "side effect" for any given change occurs when one change by one application causes a side effect change by another application. For example, the first application 210 extracts a company name from one or more data items 225, 230 associated with a given document and, if available, the name to compile a list of company stock symbols associated with the given document. To convert them into the corresponding stock symbols. If the second application 215 causes the given company name in the given metadata to be added or changed, for example, if the company name is changed from "company ABC" to "company XYZ", then the first application is "company ABC". Instead, you can listen to this change to automatically update its stock symbol list to include the stock symbol for "Company XYZ". In addition, such changes and any associated side effects may be bundled by data store 208 such that undoing one or more changes invalidates all related changes.

3 shows a system diagram illustrating the interaction between an internal data consumer with an XML data store and an external data consumer. As shown, the system 300 includes a data store 302 including a presentation layer 304, an XML store 1-N 306, each of which includes an error store and an undo store, a global change store 308. ), An optional global undo store 310, an internal broker 312 connected to an internal data consumer 1 -N 314, and an external broker 316 connected to an external data consumer 1 -N 318.

Using the XML data store (s) 306, a document may contain any number of arbitrary data items (as long as each conforms to standard XML syntax). Any metadata can be stored as XML in the document, and the information can be automatically round-tripd when the document is opened / edited / saved by the user.

As noted above, programmatic access to this data is provided through an API that can be used while the document is being edited, thereby providing a standard mechanism that is familiar to the solution developer, through which information is programmatically accessed while the document is open. May be modified). According to one embodiment, this programmatic access is designed to mimic a standard XML interface. Using the API, data can be added / removed while an application, such as a word processing application, is running, data can be populated within a repository item (part of the data store), and the data can use a standard XML constructor. Can be processed, the schema can be associated with arbitrary XML data in the data store, the schema can be added / removed / changed when associated with a data store item, and XML changes can be sent to any listening client. Can be As shown, the API provides an interface to an external broker 316 that provides an interface to an external data consumer 318 and an internal broker that provides an interface to any internal data consumer 314 that interacts with the data store 302. 312.

Manipulations to the data store 302 can occur in real time. As noted above, data store 306 may include one or more types of data. For example, a company may have one data store that is used to store all of the different types of data that it wants to store in one data store, while another company may have a different type across different data stores. You may want to store your data.

Data consumer 318 may register for events related to operations on data store 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. Other data consumers can register for changes that occur to any element or series of elements in the data store. Common events include loading a data store, adding to, and deleting from a data store. When an event occurs, each registered data consumer can react to the change, while the state of the data store remains consistent. Many times, a data consumer does not perform any action when a change is made. At other times, the data consumer performs some action (s) in response to the event. For example, a data consumer may make some other change to the data store in response to a change in title, update of a header in the document, and the like. The data consumer can also perform some other operations that do not affect the document. For example, if a stock ticker symbol is inserted, a data consumer can retrieve data associated with that stock symbol, even though not all of the retrieved data may be displayed in the document in the presentation layer. . The data consumer can also reject the change. For example, if data consumer 1 receives a change that is not accepted, the data consumer may return a flag to the broker indicating that the change is not accepted. Each time a change is not accepted, this change is rolled back with any side effects so that this change never happens. Each XML store 306 can use its undo store to undo the changes he made. As another alternative, global undo store 310 may be used to undo changes made throughout the data store. There are three data consumers interested in what's happening to the document attributes, so imagine each of those data consumers registered to receive events about changes to the attributes. When changes are made, the data store determines each data consumer that has registered and notifies each of them in a predetermined order. Each data consumer may in turn perform some action in response to this change. When any of this change or a change made by a registered data consumer as a result of this change is not accepted by any one of the data consumers, all of the changes regarding the initial change are undone.

The external broker application programming interface layer 316 provides access to the data store 302 by the external data consumer 318, and the third party client, just as the internal data consumer associated with the application interacts with the data store. Allows the user to interact with the data store 302. Each XML data store 306 in the data store 302 is provided with a unique ID for identification. This helps to find the XML data store 306.

At any point in time, the data consumer may add a schema that is used to verify data in the data store. Thus, if any other third party code now appears and attempts to change the data, the first thing the data store will do is determine if the change conforms to the provided schema. When a schema is attached, the broker becomes a verification object.

The data store can also receive more than one element at a time. Providing the data (XML) as one particular stream can help to satisfy the schema in some situations. For example, suppose the attached schema says that if stock data exists, the data must have at least two companies. If the stock data is added one by one, it is not valid.

A single pass is used to verify the data. Instead of doing two passes (which can result in changes to the data store), validation is performed before the data is committed to the data store. This helps to prevent data consumers from introducing errors into the data store.

4 and 5 illustrate a process for handling events related to data storage. In reading the descriptions of the routines provided herein, the logical operations of the various embodiments are described as (1) a sequence of computer implemented operations or program modules executed on a computer system and / or (2) interconnected machine logic circuits within a computing system or It will be appreciated that it is implemented as a circuit module. This implementation is a matter of choice depending on the performance requirements of the computing system implementing the invention. As such, the illustrated logical acts that make up the embodiments described herein are referred to in various names as acts, structural devices, acts, or modules. These operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, or any combination thereof.

4 illustrates a process for handling events associated with a data store. In general, when a data store receives a change request from a data consumer, the change is sent to all registered data consumers so that they can reject the change or request side effects (another XML change) as a result of the change. Do it.

After the start operation, the process continues to operation 410 to register for any event (s) that the data consumer is interested in receiving. This event may be about adding data to the data store, removing data from the data store, making changes to the data in the data store, and so forth. This event can be attached to a global change or a specific change to elements stored in one or more of the data stores. For example, one data consumer may want to know when any change is made, while another client may only be interested in a change to one particular value in the data store.

Proceeding to decision operation 420, a determination is made as to whether an event has occurred. This event is about changes to the data store. For example, as noted above, an event can include adding, removing, or making any other change to the data store. For example, the change may be adding a node to a data store. When no event occurs, the process returns to decision operation 420. If an event occurs, the process goes to operation 430.

In operation 430, the change is relayed to each of the data consumers that registered for the change. According to one embodiment, each data consumer is notified in a predetermined order. For example, this order may be based on the registration order of the data consumer.

Going to operation 440, a response is obtained from each of the data consumers that received the event notification. Each of the clients can accept or reject the change. This response determines whether the change will be committed to the data store.

Going to decision operation 450, a determination is made as to whether any data consumer has rejected the change to the data store. When a change is rejected by any data consumer, the process goes to block 460, and any changes made in response to the change are rolled back as if there were no changes.

If all of the notified clients accept the change, the process goes to operation 470 and the change is optionally validated and the process then goes to operation 480 where the change is committed to the appropriate data store.

The first data consumer that initiated the change is then notified that the change has been accepted (operation 490). The process then goes back to the end block and returns to processing other operations.

5 shows a process for handling events that include side effects. In general, when a data store receives a change request from a data consumer, the change is sent to all registered clients so that they can reject the change or request side effects (another XML change) as a result of the change. For example, a client can be notified of a change to one item in a data store, and as a result, the data consumer makes another change to the data store. When a change is requested as a side effect, this process is slightly different from the process shown in FIG.

After the start operation, the process goes to operation 510 and initiates side effect changes to the data store as a result of the change the client is currently accepting or rejecting.

Going to operation 520, this minor effect change is queued but not executed. In other words, side effect changes are not immediately executed within the data store. Based on this fact, alternatives to the event include the following.

Force a node action (eg, add, replace) to return a void rather than a node and record in detail that it is a request rather than an action. Make the results of node operations consistent.
No performance hits
Clear story of doing so in his AfterAdd event if you want to manipulate a node Reflects the fact that the caller "requests" the change instead of making the change. Make the results of node actions consistent
No visits Make the necessary changes to each caller, then undo them when the caller returns Return live node to caller Returns disconnect when the change is made on the event (read: node not yet committed) Return node from change in all cases Maintain a separate DOM for OM clients Return live node to caller

Going to decision operation 530, a determination is made as to whether any data consumer has rejected the first change to the data store.

When a change is rejected by any data consumer, the process goes to block 540 and any changes made in response to the change and any queuing side effect changes queued are rolled back as if no changes had occurred. .

When the client accepts the first change, the process goes to operation 550, the change is optionally verified, and the process then goes to operation 560, where the first change is committed to the appropriate data store.

The process goes to operation 570, where minor effect changes are executed one at a time in the data store. Each minor effect change is then accepted or rejected by any registered client. When any side effect change is rejected, all changes made are rolled back as if no change occurred.

The process then goes back to the end block and returns to processing other operations.

The following is an example code segment showing some of the typical functionality exposed through the data store OM.

The first example illustrates adding a stream to a data store.

Dim oStream As CustomXMLPart

Set oStream = Document.XMLStreams.Add

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

The second example shows finding a data store.

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 store.

oStream.SelectionNamespaces = oStream.SelectionNamespaces &

"xmlns: s = 'http: //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>")

According to one embodiment, the following is an example function associated with an API.

Events on CustomXMLNode

The event can be done at the document level as well as the CustomXMLNode.

AfterInsert (NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: NewNode: The CustomXMLNode object that corresponds to the node just added to the CustomXMLNode. Note: This node can have children (if a subtree has just been added to the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo by the user and FALSD otherwise.

This event is raised whenever an XML node needs to be added to the current document. If the add operation requires the subtree of the XML document to be added to the CustomXMLNode, this event occurs once for the top node in the change. This event occurs once for each change sent as a message to the data store, so the side effect of the change represented by this event also triggers the event.

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

Parameters: OldNode: The CustomXMLNode object corresponding to the node just removed from the CustomXMLPart. Note # 1: (If the subtree is removed from the document) This node can have children. Note # 2: This node is a "disconnected" node in that it is queried down from this node and cannot go up-it appears to exist alone-(ie it is a document element with the same OwnerStream). OldParentNode: A CustomXMLNode object corresponding to the old parent node of the OldNode. OldNextSibling: CustomXMLNode object corresponding to previous next sibling node of OldNode. InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo by the user and FALSE otherwise.

This event occurs whenever an XML node is deleted from the current item in the data store. If the delete operation requires a subtree of XML documents in the CustomXMLPart, this event fires once for the top node in the change. This event occurs once for each change sent in a message to the data store, so the side effect of the change represented by this event also triggers the event.

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

Parameters: OldNode: The CustomXMLNode object corresponding to the node just removed from the CustomXMLPart. Note # 1: (If the subtree is removed from the document) This node can have children. Note # 2: This node is a "disconnected" node in that it is queried down from this node and cannot go up-it appears to exist alone-(ie it is a document element with the same OwnerStream). NewNode: CustomXMLNode object that corresponds to the node just added to the CustomXMLPart. Note: This node can have children (if a subtree is added to the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo by the user and FALSE otherwise.

This event occurs whenever an XML node is replaced in the data store. If the replacement action requires a subtree of XML documents in the CustomXMLPart, this event fires once for the top node in the change. This event occurs once for each change sent in a message to the data store, so the side effect of the change represented by this event also triggers the event.

CustomXMLParts (): Refers to the collection of all data store items available in the file, including OLE document properties and WSS property streams.

CustomXMLPrefixMappings: An object representing all of the prefix mappings for the current part.

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

Parameters: Prefix: a String indicating the prefix to add to the prefix mapping list. NamespaceURI: A String representing the namespace to assign to the newly added prefix.

Allows the developer to add custom namespace / prefix mappings when querying this item. If a prefix already exists in the manager, this overwrites the meaning of that prefix, except when the prefix is being added / used internally by the data store, the error "This prefix is already in use and cannot be modified". Returns.

Count As Long: Returns the number of prefix mappings in the collection.

Item (Index as Long) As CustomXMLPrefixMapping

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

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

LookupNamespace (Prefix As String) As String

Parameters: Prefix: a String representing the prefix in the prefix mapping list. Allows a developer to get a namespace that corresponds to a specified prefix. If the requested prefix is not assigned to a namespace, return "".

LookupPrefix (NamespaceURI As String) As String

Parameters: NamespaceURI: a String representing the prefix in the prefix mapping list.

Allows a developer to get a namespace that corresponds to a specified prefix. If the requested prefix is not assigned to a namespace, return "". If multiple prefixes are specified in the namespace manager, the first one that matches the provided namespace is returned.

CustomXMLPrefixMapping: An object representing prefix mapping.

Prefix As String: Returns the prefix for this prefix mapping.

NamespaceURI As String: Returns the namespace for this prefix mapping.

CustomXMLSchema: An object that represents a schema that is part of a schema collection.

Delete As Void: Delete this schema from the schema collection. If this is done for a schema in a collection that has already been verified or attached to the stream (various types of live collections), it fails with the error message "This schema cannot be deleted because the schema collection is currently in use."

Location As String: Returns a string indicating the location of this schema on the user's machine.

NamespaceURI As String: Returns the target namespace "" of this schema if nothing is specified by the XSD.

Reload As Void: Reloads this schema from disk, relocates a copy of this schema on disk (if the SL has changed), locates it and ensures that it is still a valid schema. If this is done for a schema in a collection that has already been verified or associated with a stream (various types of live collections), it fails with the error message "This schema cannot be reloaded because the schema collection is currently in use."

CustomXMLSchemaCollection (): An object representing the collection of schemas (attached to / attached to the stream).

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

Parameters: NamespaceURI: A String representing the namespace of the schema to be added to the collection. If the schema exists in the schema library, retrieve it from there. Alias: A String representing the alias of the schema to add to the collection. If this alias exists in SL, this argument is used to find it. FileName: A String representing the location on disk where the schema can be found. If this parameter is specified, the schema is added to the collection as well as to the SL. InstallForAllUsers: Boolean indicating if the SL key is written to HKLM (for all users) or to HKCU (only for current user) when adding schemas to the schema library. Default is False (written to HKCU).

This method allows a developer to add one or more schemas to the collection of schemas to be added to the stream from the data store. It can be called with the following set of parameters (in case of conflict, try to use the parameters in the following order): [NamespaceURI], [Alias], FileName, [InstallForAllUsers] (the schema for that namespace If it does not exist, add the schema to the schema library). Just NamespaceURI (search for XSD from schema library). Just Alias (search for XSD from schema library).

AddCollection (SchemaCollection As CustomXMLSchemas ()) As Void

Parameters: SchemaCollection: A CustomXMLSchemas () object representing the collection of schemas to be imported into the current collection.

Appends an existing collection to the current collection. If namespaces conflict during import (for example, if a.xsd is already linked to "fooNamespace" but the incoming collection has b.xsd for the same namespace), the incoming collection takes precedence.

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

Item (Index as Variant) As CustomXMLSchema

Parameters: Index: a variable representing the desired item in the collection. This can be either a String representing the target namespace of the desired schema or a Long representing the index of the desired schema in the collection.

Returns a CustomXMLSchema requested from the collection. Default member of this object.

NamespaceURI (Index as Long) As String

Parameters: Index: Long representing the index of the schema in the collection.

Returns the target namespace of the specified member of the schema collection.

Validate As Boolean: Returns a Boolean indicating whether the schema in the collection has been validated. Also, this is when the Include is traversed for each schema in the collection and adds them to the schema that requested them.

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

Add ([XML As String], [SchemaCollection as CustomXMLSchemaCollection ()]) As CustomXMLPart

Parameters: XML: An optional String representing the XML to add to the newly created CustomXMLPart. SchemaCollection: An optional CustomDataSchemaCollection () object that represents the set of schemas used to validate this stream.

Allows the user to add new CustomXMLParts to a file. If the XML in the XML parameter is not well formed, it fails and throws an error "In order to add content to this stream, the content must be valid and well formed XML". If the user provides a SchemaCollection, it validates it (if it hasn't been verified yet). Streaks cannot be added by throwing any MSXML parsing errors received back into the OM client. Check that an XML parameter can be loaded into the DOM. If it cannot be loaded, it fails and throws an error "To add content to the stream, it must be valid and well-formed XML". Attach a schema collection to the DOM and try to validate the instance document. If it is not verified, it fails and throws an XML parsing error received back from the OM client and does not add the stream to the collection.

If the user does not provide a SchemaCollection, check that XML parameters can be loaded into the DOM. If it cannot be loaded, it fails and throws an error "In order to add content to the stream, it must be valid and well-formed XML". View a list of namespaces referenced in the XML file. Find the schemas from the SL and infer the schema collection for them. Attempt to validate the resulting schema collection. If it is not verified, it still adds the stream to the collection, but it is not associated with any schema collection and therefore not verified. Attach a schema collection to the DOM and try to validate the instance document. If it is not verified, it fails and throws an XML parsing error received back from the OM client and does not add the stream to the collection. If it is not verified, it still adds the stream to the collection, but it is not associated with any stream collection and therefore not verified. Providing an empty SchemaCollection is an explicit behavior that is thought to mean "never validate this stream."

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

Item (Index As Variant) As CustomXMLPart

Parameters: Index: A variable that can be one of the following two types: a Long representing the index of the desired CustomXMLPart in the collection or a String representing the root namespace of the desired CustomXMLPart in the collection. If two or more parts match this root namespace, the first match in the index order is returned.

This is the default member of the CustomXMLParts object, which returns a CustomXMLPart object corresponding to the requested object.

SelectByID (ID As String) As CustomXMLPart

Parameters: ID: a String containing the ID for the data store item that should be returned from the collection.

It allows a developer to use a particular item from the data store using his ID. If no repository entry with this ID exists, nothing is returned.

SelectByNamespace (NamespaceURI As String) As CustomXMLParts ()

Parameters: NamespaceURI: A String representing the root namespace of the desired items from the collection of data stores.

Returns all data store entries with a root namespace matching the requested entry. If no stream exists with this root namespace, an empty CustomXMLParts () collection is returned.

StreamAfterAdd (NewStream As CustomXMLPart)

Parameters: NewStream: CustomXMLPart object containing the stream just added

This event occurs whenever a new stream is added to the data store. If multiple streams are added, this event occurs once for each new stream. If a stream with XML content is added (using the appropriate .Add method), this event does not occur until the item is filled with that content.

StreamBeforeDelete (OldStream As CustomXMLPart)

Parameters: OldStream: A CustomXMLPart object containing the stream to be removed from the data store.

This event occurs whenever a stream is removed from the data store. If multiple streams are removed, this event occurs once for each stream deleted. You can also flag this stream as "to be deleted" so that read-only operations (e.g., querying the node, checking values, etc.) are valid, but the write operation is "deleted." Fail with the error message "Cannot be performed on stream."

CustomXMLPart: an object representing a single XML stream in the data store

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

Parameters: Name: a String representing the base name of the node to be added to the XML DOM. Namespace: an optional String representing the namespace of the node to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute; otherwise it is ignored. Parent: CustomXMLNode that represents the node to which this node should be added below it. When adding an attribute, indicate the element to which the attribute should be added. NextSibling: an optional CustomXMLNode that represents the node that should be the next sibling of the new node. If not specified, this node is added to the end of the children of the parent node. Ignored for addition of type msoXMLNodeAttribute. If NextSibling is not a child of the parent, it returns the error "This node cannot be added because the next sibling is not a child of the parent node." NodeType: optional msoCustomXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String used to set the node's value for nodes that accept text. If the node does not allow text, this parameter is ignored.

Common way to add an XML node to a data store item. Requires parent and NodeType defaults to msoXMLNodeElement. If the addition of the result is not structurally valid, it fails with the error "This operation cannot be performed because the result is a structurally invalid data stream." If the namespace is not in the schema reference collection, it fails and gives the error message "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, nothing is returned.

Delete As Void: Deletes the current CustomXMLPart from the data store. If the user tries to delete the core attribute part, it fails with the error "This custom XML part 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: a String object corresponding to a file on the user's machine (or network, etc.) for which XML for this CustomXMLPart should be loaded from it.

Allows template authors to populate CustomXMLParts from existing files on his machine. Returns TRUE if the load was successful, otherwise FALSE (including when structure enforcement is on and the XML is not structurally valid or the XML is invalid and / or poorly formed). Returns. When the DOM is loaded, it fails with "This DOM cannot be loaded twice."

LoadXML (XML As String) As Boolean

Parameters: XML: a String object corresponding to the XML that should be loaded into this CustomXMLPart.

Allows template authors to populate CustomXMLParts from strings of XML. Returns TRUE if the load was successful, otherwise returns FALSE (including if structural enforcement is on and the XML is not structurally valid or if the XML is invalid and / or poorly formed). When the DOM is loaded, it fails with "This DOM cannot be loaded twice".

NamespaceURI As String: Returns a string containing the full namespace URI for the root node of the current CustomXMLPart. If the stream is empty (created but no nodes have been added), it returns "".

SchemaCollection As CustomnXMLSchemaCollection (): Gets / sets the CustomXMLSchemaCollection () collection that represents the set of schemas attached to this stream. If the user provides a SchemaCollection, verify it (if not yet verified). It throws any parsing errors received back into the client and fails to add a stream, attaches a schema collection to the DOM, and attempts to validate the instance document. If it is not verified, it fails and throws a parse error received back from the client and does not change the schema collection for the stream.

NamespaceManager As CustomXMLPrefixMappings ()

Gets a set of namespace prefix mappings used for the current CustomXMLPart. When the document is opened, it is automatically populated with the content of the prefix mapping embedded in the data store item, but cannot be edited / added / deleted by the template author. However, according to one embodiment, changes to this parameter are not stored with the document.

SelectNodes (XPath As String) As CustomXMLNodes ()

Parameters: XPath: A String containing the XPath expression to evaluate against the DOM. The prefix mapping for this XPath is retrieved from the associated namespace manager. If the XPath is not resolved, it passes through which error occurs.

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

SelectSingleNode (XPath As String) As CustomXMLNode

Parameters: XPath: A String containing the XPath expression to evaluate against the DOM. The prefix mapping for this XPath is retrieved from the associated namespace manager. If the XPath is not resolved, then any error occurs.

This method allows the developer to get back a node from inside the DOM.

XML As String: Returns an XML representation of the current CustomXMLPart.

NodeAfterInsert (NewNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: NewNode: The CustomXMLNode object that corresponds to the node just added to the CustomXMLPart. This node can have children (if the subtree is just added to the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo action by the user, and FALSE otherwise.

This event is raised whenever an XML node is about to be added to the current document. Raise this event once for the top node in the change if the add operation requires that the subtree of the XML document be added within the CustomXMLPart. This event is fired once for each change sent as a message to the data store, so the side effect of the change represented by this event also triggers the event.

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

Parameters: OldNode: The CustomXMLNode object corresponding to the node just removed from the CustomXMLPart. Note # 1: This node can have children (if the subtree is being removed from the document). Note # 2: The query can be made down from the node, but in the sense that it does not go up, this node becomes a "disconnected" node-this node appears to exist alone (ie it is a document element with the same OwnerStream). ). OldParentNode: A CustomXMLNode object corresponding to the old parent node of the OldNode. OldNextSibling: CustomXMLNode object corresponding to the previous next sibling of OldNode. InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo action by the user and FALSE otherwise.

This event is raised whenever an XML node is deleted from the current item in the data store. If the delete operation involves a subtree of the XML document in the CustomXMLPart, this event is fired once for the top node in the change. This event is fired once for each change sent as a message to the data store, so the side effect of the change represented by this event also triggers the event.

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

Parameters: OldNode: The CustomaXMLNode object corresponding to the node just removed from the CustomXMLPart. Note # 1: This node can have children (if the subtree is being removed from the document). Note # 2: This node becomes a "disconnected" node in that queries can be made down from this node but not up-it appears to exist alone (ie it is a document element with the same OwnerStream). ). NewNode: CustomXMLNode object that corresponds to the node just added to the CustomXMLPart. Note: This node can have children (if the subtree has just been added to the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo action by the user and FALSE otherwise.

This event is raised whenever an XML node is replaced in the data store. If the fallback action requires a subtree of the XML document in the CustomXMLPart, this event is fired once for the top node in the change. This event is fired once for each change sent as a message to the data store, so the side effect of the change represented by this event also triggers the 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: a Long indicating the index of the desired CustomXMLNode in the collection.

This is the default member of the CustomXMLNode object, which returns a CustomXMLNode object that corresponds to the requested item in the collection.

CustomXMLNode

AppendChildNode ([Name As String], [NamespaceURI As String], [NodeType As msoCustomXMLNodeType], [Node Value As String]) As Void

Parameters: Name: optional String representing the base name of the element to be added to the XML DOM. Namespace: an optional String representing the namespace of the element to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, otherwise it is ignored. NodeType: optional msoCustomXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String used to set the node's value for nodes that accept text. If the node does not allow text, this parameter is ignored.

If the context node is of type msoXMLNodeElement, it allows the developer to add a single node as the last child under the context element in the tree. Otherwise, this method fails with the error "Cannot attach child to comment, processing instruction or attribute."

It also blocks the case where the node to be added is an already existing attribute. "An attribute with the same name already exists in the current element."

AppendChildSubtree (XML As String) As Void

Parameters: XML: A String representing the subtree to be added to the XML DOM. This XML must be a well-formed XML document (including namespace declarations, single root nodes, etc.). Otherwise, it fails with the error "In order to add an XML subtree to your document, it must contain valid and well-formed XML".

If the context node is of type msoXMLNodeElement, it allows the developer to add an existing well-formed XML subtree as the last child under the context element in the DOM. Otherwise, it fails with the error "Cannot attach child to comment, processing instruction or attribute".

Attributes As CustomXMLNodes (): returns a Collection of CustomXMLNodes representing the attributes on the current element.

BaseName As String: This is the base member of the CustomXMLNode. This returns the base name of a node that does not have a name space prefix if it exists in the DOM.

ChildNodes As CustomXMLNodes: Returns a Collection of CustomXMLNodes containing all of the elements that are children of the current node.

Delete As Void: Deletes the current node (including all its children, if present) from the XML DOM. If the deletion of the result is not structurally valid, it fails with the error message "This operation cannot be performed because this results in a structurally invalid DOM."

FirstChild As CustomXMLNode: Returns a CustomXMLNode object corresponding to the first child element of the current node. If this node has no element children (or it is not of type msoCustomXMLNodeElement itself), nothing is returned.

HasChildNodes As Boolean: Returns a Boolean that is true if the current node has child element nodes; otherwise, False. This returns false when the CustomXMLNode is not a NodeType msoCustomXMLNodeElement.

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

Parameters: Name: a String representing the base name of the element to be added to the XML DOM. Namespace: an optional String representing the namespace of the element to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, otherwise it is ignored. NodeType: optional msoCustomXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String used to set the node's value for nodes that accept text. If the node does not allow text, this parameter is ignored. NextSibling: An optional CustomXMLNode object that specifies the node before which new XML elements should be added to the tree.

Inserts a new child node into the tree at the specified position. If a BeforeNode does not exist when adding a node of type msoCustomXMLNodeElement, msoCustomXMLNodeComment, or msoCustomXMLNodeProcessingInstruction, this node is added to the end of the list. If added for type msoCustomXMLNodeAttribute, it is ignored. If NextSibling is not a child of the context node, the method fails with the error "This XML node cannot be added because the next sibling element must be a child of the context element." If the addition of the result is structurally invalid (and also schema enforcement is on), it fails with the error message "This operation cannot be performed because this results in a structurally invalid DOM." It also blocks the case where the node to be added is an already existing attribute. "An attribute of the same name already exists in the current element."

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

Parameters: XML: A String representing the subtree to be added to the XML DOM. This XML must be a well-formed XML document (including namespace declarations, a single root node, etc.). Otherwise, it fails with the error "In order to add an XML subtree to a document, it must contain valid and well-formed XML." NextSibling: an optional CustomXMLNode object that specifies the node where the new XML element should be added to the tree before it

Inserts the specified XML subtree into the set of child nodes at the specified position. If NextSibling is not a child of the context node, this method fails with "This XML node cannot be added because the next sibling must be a child of the context element." If the addition of the result is not structurally valid, it fails with the error message "This operation cannot be performed because this results in a structurally invalid DOM."

LastChild As CustomXMLNode: Returns a CustomXMLNode object corresponding to the last child element of the current node. If the node has no child elements (or not of type msoCustomXMLNodeElement itself), nothing is returned.

NamespaceURI As String [read-only]

Returns a String that corresponds to the namespace of the current node. If the node is of type msoCustomXMLNodeComment, msoCustomXMLNodeProcessingInstruction, it returns "".

NextSibling As CustomXMLNode: Returns the next sibling node (element, comment, or processing instruction) of the current node. If the node is the last sibling in its level, nothing is returned.

NodeType As msoCustomXMLNodeType: Returns the msoCustomXMLNodeType constant indicating the type of the current node.

Node Value As String: Gets / sets text inside nodes that contain only text (ie text nodes, comments, processing instructions, attributes). For an element, it fails with "Unable to set node value for element node".

OwnerDocument As Variant: Returns a document / workbook / presentation object that represents the word document associated with this node.

OwnerStream As CustomXMLPart: Returns a CustomXMLPart object representing the data store item associated with this node.

PreviousSibling As CustomXMLNode: Returns the previous sibling node (element, comment or processing instruction) of the current node. If this node is the first sibling in its level, nothing is returned.

ParentNode As CustomXMLNode: Returns the parent element node of the current node. If this node is at the root level, nothing is returned.

RemoveChild (Child As CustomXMLNode) As Void

Parameters: Child: A CustomXMLNode object that represents the child nodes of the context node to be removed. If this node is not a child of the context node, it fails with the error message "This node cannot be deleted because it is not currently a child of the element."

Remove the specified child node from the stream. If the resulting DOM is not structurally valid, it fails with the error message "This operation cannot be performed because a DOM that is structurally invalid" is encountered.

ReplaceChildNode (Name As String, [Namespace As String], [NodeType As msoCustomXMLNodeType], [Node Value As String], OldNode As CustomXMLNode) As Void

Parameters: OldNode: CustomXMLNode representing the child node to be replaced. Name: A String representing the base name of the element to be added to the XML DOM. Namespace: an optional String representing the namespace of the element to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, otherwise it is ignored. NodeType: optional msoCustomXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoCustomXMLNodeElement. NodeValue: An optional String used to set the node's value for nodes that accept text. If this node does not allow text, this parameter is ignored.

Removes the specified child node (and its subtrees) from the stream and replaces it with the node specified at the same location. If OldNode is not a child of the context node, it fails with the error message "OldNode must be a child of the current node." If the replacement of the result is not structurally valid, it fails with the error message "This operation cannot be performed because a DOM that is not structurally valid" is encountered. It also blocks the case where the node to be added is an already 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 representing the subtree to be added to the XML DOM. This XML must be a well-formed XML document (including namespace declarations, single root nodes, etc.). Otherwise, it fails with the error "To add an XML subtree to a document, it must be valid and well-formed XML".

Removes the specified node (and its subtrees) from the stream and replaces the node at the same location with the specified XML subtree. If OldNode is not a child of the context node, it fails with the error message "OldNode must be a child of the current node." If the replacement of the result is not structurally valid, it fails with the error message "This operation cannot be performed because a structurally invalid DOM is created."

SelectNodes (XPath As String) As CustomXMLNodes ()

Parameters: XPath: A String containing the XPath expression to evaluate against the DOM. The prefix mapping for this XPath is retrieved from the NamespaceManager property. If the XPath is not resolved, any error will be passed (according to this method on the Document object with the currently embedded XML).

This method allows a developer to get back a set of nodes from within a data store item.

SelectSingleNode (XPath As String) As CustomXMLNode ()

Parameters: XPath: a String representing the XPath expression to evaluate against the DOM. The prefix mapping for this XPath is retrieved from the NamespaceManager property. If the XPath is not resolved, any error will be passed (according to this method on the Document object with the currently embedded XML).

This method allows developers to retrieve a single node back from within a data store item.

Text As String: Gets / sets the text for the current node. Unlike MSXML, setting this for a node replaces the contents of that node with the specified string-for example, "test" for a non-leaf element <foo> if the content of foo is (test) "setting

<foo>

Bar

<baz> hello </ baz>

</ foo>

It doesn't fail, but it results in different messages internally to the data store and externally to clients of the data store. If the replacement of the result is not structurally valid, it fails with the error message "This operation cannot be performed because a DOM that is not structurally valid" is encountered.

XML As String: Returns the raw XML representation of the current node and its children, if any.

XPath As String: Returns a String with the canonicalized XPath for the current node. If the node is no longer in the DOM (deleted), it fails with "This node has been deleted from the associated custom XML part."

New Enums: msoCustomXMLDataNodeType indicates the type of XML node available. msoCustoniXMLNodeAttribute represents an XML attribute node. msoCustomXMLNodeCData represents a CDATA node. msoCustomXMLNodeComment represents an XML comment node. msoCustornXMLNodeDocument represents an XML document (/) node. msoCustomXMLNodeElement represents an XML element node. msoCustomXMLNodeProcessingInstruction represents an XML processing instruction node. msoCustomXMLNodeText represents a text node.

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 nodes of the context node to be removed. If this node is not a child of the context node, it fails with the error message "This node cannot be removed because it is not a child of the current element." Name: A String representing the base name of the element to be added to the XML DOM. Namespace: an optional String representing the namespace of the element to be added to the XML DOM. Required to add a node of type msoXMLNodeElement or msoXMLNodeAttribute; otherwise it is ignored. NodeType: optional msoXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoXMLNodeElement. NodeValue: An optional String used to set the node's value for nodes that accept text. If the node does not allow text, this parameter is ignored.

Removes the specified child node (and its subtrees) from the stream and replaces it with the node specified at the same location. If deletion of the result is structurally invalid (and schema enforcement is on), it fails with the error message "This operation cannot be performed because a structurally invalid DOM is created."

XMLNamespace: An object that represents a single unique namespace in the schema library.

AttachToCustomXMLPart (CustomXMLPart As Variant) As Void

Parameters: CustomXMLPart: A variable that can be the CustomXMLPart object for the desired stream or the index of that stream in the CustomXMLParts collection.

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

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

Delete () As Void: Removes the namespace-as well as all elements within that namespace-from the CustomXMLPart. However, in this case, because structural schema enforcement is enabled, the data store can reject this behavior, and removing these elements results in a DOM that is structurally invalid. In this case, it fails and throws the error "This operation cannot be performed while schema enforcement is enabled because the stream of this result is 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 representing the base name of the element to be added to the XML DOM. Namespace: an optional String representing the namespace of the element to be added to the XML DOM. Required to add a node of type msoXMLNodeElement or msoXMLNodeAttribute; otherwise it is ignored. Parent: An optional CustomXMLNode that represents the node to which this node should be added below it. If canceled from the CustomXMLNodes collection returned by the .Attributes property, it is assumed to be the parent node of the attribute. If called in any other case, this parameter is specified or returns the error "You must specify the parent node to add this node to the document." NextSibling: an optional CustomXMLNode that represents the node that should be the next sibling of the new node. If not specified, this node is added to the end of the children of the parent node. The addition of the type msoXMLNodeAttribute is ignored. If NextSibling is not a child of the parent, it returns the error "This node cannot be added because the next sibling is not a child of the parent node." NodeType: optional msoXMLNodeType that specifies the type of node to generate. If not specified, it is assumed to be msoXMLNodeElement. Unless canceled from the .Attributes attribute, it is assumed to be msoXMLNodeAttribute. NodeValue: An optional String used to set the node's value for nodes that accept text. If the node does not allow text, this parameter is ignored.

Common way to add XML nodes to data store items. When canceled from the CustomXMLNodes object returned by the .Attributes attribute, Parent has the default value of the parent node and NodeType has the default value of msoXMLNodeAttribute. In all other cases, Parent is required and NodeType defaults to msoXMLNodeElement. If the addition of the result is not structurally valid (and schema enforcement is on), the error message "This operation cannot be performed while schema enforcement is on because a structurally invalid data stream is created." To fail. If the namespace is not in the schema reference collection, it fails with the error 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 the CustomXMLPart. Note: By default, this is populated with an entry 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: A String containing the namespace defined by the schema to add to the schema collection. Alias: A String containing the alias to write when adding this schema to the schema library. FileName: A String containing the path to the schema that should be added to the schema library. InstallForAllUsers: Boolean that determines if schema library keys should be added to HKCU (default) or HKLM.

This method adds a schema reference. To do this, add the appropriate namespace declaration to the root element of the CustomXMLPart, if it is not already defined in the file. When open, all declared namespaces are used to populate this collection.

EnforceStructure As Boolean: Gets / sets a Boolean that corresponds to whether the data store should enforce structural validation on the associated CustomXMLPart according to its schema. If the user attempts to set this attribute to TRUE while the content of the CustomXMLPart is invalid, it will return an error that "Schedule enforcement cannot be turned on while the content of this data stream is structurally invalid."

Count As Long: Returns the number of namespaces currently referenced in this CustomXMLPart.

Item (Index As Variant) As XMLSchemaReference

Parameters: Index: A variable that can be one of the following two types: a Long representing the index of the CustomDataXMLSchemaReference desired in the collection, or a String representing the namespace of the CustomDataXMLSchemaReference desired in the collection.

This is the default member of the CustomDataXMLSchemaReferences object, which returns an XMLSchemaReference object corresponding to the requested object.

Validate () As Void: This method validates the entire stream against all the schemas in the CustomDataXMLSchemaReferences collection. An error is reported for each node (see the .ValidationStatus property).

CustomXMLNode

NodeAfterInsert (NewCustomXMLNode as CustomXMLNode, InUndoRedo as Boolean).

Parameters: NewCustomXMLNode: The CustomXMLNode object that corresponds to the node just added to the CustomXMLPart. Note: This node can have children (if the subtree has just been added to the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo action by the user and FALSE otherwise.

This event is raised whenever an XML node is about to be added to the current document. If the add operation requires a subtree of XML document to be added to the CustomXMLPart, fire this event once for the top node in the change. This event occurs once for each change that is sent to the data store as a message, so the side effect of the change represented by this event also triggers the event.

NodeBeforeDelete (OldCustomXMLNode as CustomXMLNode, InUndoRedo as Boolean)

Parameters: OldCustomXMLNode: A CustomXMLNode object corresponding to the node that is about to be removed from the CustomXMLPart. Note: This node can have children (if the subtree is being removed from the document). InUndoRedo: A Boolean that returns TRUE if the node was added as part of an undo / redo action by the user and FALSE otherwise.

This event is raised whenever an XML node is deleted from the current item in the data store. If the delete operation requires a subtree of the XML document in the CustomXMLPart, this event is fired once for the top node in the change. This event is fired once for each change sent as a message to the data store, so the side effect of the change represented by this event also triggers the event. If the event handler tries to modify anything that is under this node, it fails with the error message "This change is not allowed because this node will be deleted."

The above specification, 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 practiced without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims (20)

A tangible computer-readable medium having computer-executable instructions for managing data associated with a computer-generated document, The computer-executable instructions are Storing structured data items associated with a document in a data store maintained separately from document data for the document, the document data subjecting to a primary presentation for displaying the document. And the structured data item is represented in Extensible Markup Language (XML), the structured data item is metadata about a document, and the structured data item is deleted from the data store until the document is deleted. Remains associated with-Wow, APIs (Application Programming Interfaces) allow the programmatic access to the structured data items by each of a plurality of different client data consuming applications. Formatting the structured data item to be exposed to a consuming application, wherein execution of the API accesses the structured data item in the data store while the document is open for editing and when the document is closed for editing. The API, which provides functionality and allows programmatic access to the structured data item by the data consuming application, allows multiple data consuming applications to simultaneously access the same structured data item, the API being arbitrary And, - wherein the data consuming application also allows for storing the structured data item in the data store Registering a notification of a change by the data consuming application; Using the API to determine when a change is made to one of the structured data items, and when the change is made, notify the registered data consuming application of the change; In response to the notification of the change, queuing a side-effect change by one of the data consuming applications, wherein the side effect change is generated based on data associated with the notified change. Wow, Notifying the registered data consuming application of the side effect change. Computer-readable media. The method of claim 1, The computer-executable instructions are Rolling back the change when one of the registered data consuming applications rejects the change and committing the change to the data store when each of the registered data consuming applications accepts the change. To do more Computer-readable media. 3. The method of claim 2, The computer-executable instructions are Further using the API to associate the structured data item with an XML schema file that is used to validate the structured data item before the change is committed to the data store. Computer-readable media. The method of claim 1, The API provides a function to register to receive a notification of a change notification for at least one of a change to the data store and a change to one or more of the structured data items, the change being the data store. And at least one of deletions, additions, and modifications to at least one of the structured data items. Computer-readable media. 5. The method of claim 4, The API provides an interface for adding a node to the data store, deleting a node from the data store, and replacing a node within the data store. Computer-readable media. 5. The method of claim 4, The API populates the data store using an existing file and provides an interface for populating the data store using a string of XML. Computer-readable media. 5. The method of claim 4, The API provides an interface for adding namespaces, browsing namespaces, adding schemas, deleting schemas, and reloading schemas. Computer-readable media. 5. The method of claim 4, The API adds a stream, removes a stream, adds a subtree, removes a subtree, obtains the next sibling of the current node, and the previous sibling of the current node. To provide an interface for obtaining a node type Computer-readable media. 5. The method of claim 4, The API provides an interface for obtaining node values and enforcing the structure. Computer-readable media. A computer-implemented method of managing data associated with computer-generated documents, Storing a structured data item associated with a document using a data store, wherein the structured data item is structured according to Extensible Markup Language (XML), the structured data item is metadata for a document, and Structured data items remain associated with the document until deleted from the data store; Formatting the structured data item to expose application programming interfaces (APIs) to a first data consuming application that allows programmatic access to the document and the structured data item included in the data repository; The structure in the data store both while the document is edited and when the document is closed for editing, such that the structured data item is linked to the document and serves as metadata describing the characteristics of the document. Executing the API to access a data item, wherein the first data consuming application receives a notification of a change made in the data store when registered; Using the API to initiate a change in one of the data stores; Providing the notification to a second registered data consuming application associated with the change; Queuing a side effect change in response to the notification at the second registered data consuming application; Determining whether a response from the second registered data consuming application is a rejection, and rolling back the change and the side effect change if the response is rejection; Determine whether the registered first data consuming application and the second registered data consuming application accept the change and the side effect change, and register the registered first data consuming application and the second registered Selectively validating the changes and minor effect changes using an XML schema file provided from one of the data consuming applications using an API when a data consuming application accepts the changes and the minor effect changes; And  Committing the change and the minor effect change to one or more of the data stores; Computer-implemented method. The method of claim 10, The steps of using the API are to get the value of a node, add a node, delete a node, move a node, add a schema, delete a schema, reload a schema, add a namespace, Providing a programming interface for deleting the namespace; Computer-implemented method. A system for managing data associated with computer-generated documents, A processor; A tangible storage medium coupled with the processor; A data consuming application for running on the processor; A document data store for storing documents on said tangible storage medium; And A data repository associated with said data consuming application for storing structured data items associated with one or more said documents, The structured data item remains associated with the one or more documents until removed from the data store, The data store, XML data store; An API broker for interacting with the data consuming application; A change repository for storing changes related to changes made to the structured data items; And An undo store for rolling back any changes made as a result of the changes made to the structured data item, The API broker exposes application programming interfaces (APIs) that allow programmatic access to the structured data items stored in the document and the data repository, The data consuming application executes the API to access the structured data item in the data store both while the document is open and when the document is closed, thereby linking the document with the item in the data store. To provide a programmatic link to the data consuming application, The data consuming application also queues side effect changes when an item in the data store changes. system. The method of claim 12, The data store also, Receive a change to Extensible Markup Language (XML) markup data applied to the structured data item, Read an XML schema file associated with the structured data item associated with the change to the XML markup data, Determine whether a change to the XML markup data is valid according to the read XML schema file, If the change to the XML markup data is invalid according to the read XML schema file, the change to the XML markup data is not allowed and the change to the XML markup data according to the read XML schema file is not allowed. Commit the change to one or more of the XML repositories if valid system. The method of claim 12, Each of the XML data stores includes an undo store and a change store. system. The method of claim 12, The API provides an interface for adding a node to the data store, deleting a node from the data store, replacing a node within the data store, and obtaining a value from the data store. system. 16. The method of claim 15, The API provides an interface for adding schemas, deleting schemas, and reloading schemas. system. delete delete delete delete

Images