JP5072845B2 - Programmability for XML data store for documents - Google Patents

Description

  The present invention relates to a method and system for managing data associated with computer-generated documents, and to programmability for an XML data store for documents.

  Computer users have become accustomed to user-friendly software applications that help them write, calculate, plan, prepare presentations, send and receive e-mail, make music, and more. For example, word processing applications allow users to create a variety of useful documents. Spreadsheet applications allow users to enter, manipulate and organize data. Slide presentation applications allow users to create a variety of slide presentations that contain text, pictures, data, or other useful objects.

  However, documents created by such applications (eg, word processing documents, spreadsheets, slide presentation documents) can be used to store / transport any metadata content required by the document context. The mechanism is limited. For example, a solution built on top of a word processing document can include various states of the document, such as the previous workflow approval state (date, time, name), current approval state, future workflow state before completion, It may be necessary to store workflow data that describes the author's name and office address, document changes, etc. of the document. Options for storing this information are mainly limited to the use of document variables or existing custom OLE (object linking and embedding) document properties with restrictions. For example, hierarchical data cannot be stored, character length is limited, and the like. Properties for such methods are stored in a single store, such as the OLE property store, which means that the properties have the potential for collisions. Furthermore, such stored properties do not have data validation. It is difficult for users of such applications and related documents to store arbitrary data along with the document, and this is commonly required by many users.

  This summary is provided below to introduce a collection of concepts in a simplified form that are further described below in the detailed description. This summary is intended to identify important or essential features of the claimed subject matter, but may be used as an aid in determining the scope of the claimed subject matter. It is not intended.

  One or more data stores are maintained separately from the main presentation storage in the document to store, relate and allow any data associated with the computer-generated document . Data for structuring information associated with a document, such as document metadata, is maintained in a data store where relationships between different data are maintained. The data store exposes an application programming interface (API) to various data in the data store so that various applications can access and interact with one or more of the data.

  The data can be structured according to a markup language such as Extensible Markup Language (XML). 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. While the document is being edited, data in XML form can be programmatically accessed. Multiple client applications can access and edit the same document data, and any conflicting changes to the given data are resolved. It also uses any standard XML schema (XSD) to ensure that the XML data applied to the document data is valid and that any custom XML data content associated with the document metadata is Can be defined.

  Various aspects of the invention will now be described with reference to the drawings, in which like numerals represent like elements. Specifically, FIG. 1 and corresponding discussion are intended to briefly and generally describe 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. A distributed computing environment can 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 can be located in both local and remote memory storage devices.

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

  The computing device 100 can have additional features or functions. For example, computing device 100 may also include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical disks, or tapes. Such additional storage is illustrated in FIG. 1 by removable storage 109 and non-removable storage 110. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. May be included. System memory 104, removable storage 109, and non-removable storage 110 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disc (DVD), or other optical storage, magnetic cassette, magnetic tape , Magnetic disk storage, or other magnetic storage device, or any other medium that can be used to store desired information and accessed by computing device 100. Any such computer storage media can be part of device 100. The computing device 100 can also have an input device 112, such as a keyboard, mouse, pen, voice input device, touch input device, and the like. An output device 114 can also be included, such as a display, speakers, printer, etc. All these devices are well known in the art and need not be discussed at length here.

  The computing device 100 can also include a communication connection 116 that allows communication with other computing devices 118, such as over a network. Communication connection 116 is an example of a communication medium. Communication media are typically exemplified by computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term “modulated data signal” means 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. As used herein, the term computer readable medium includes both storage media and communication media.

  Some program modules and data files include an operating system 105 suitable for controlling the operation of networked personal computers, such as the WINDOWS® operating system of MICROSOFT Corporation of Redmond, Washington. It can be stored in the system memory 104 of the device 100. The system memory 104 can also store one or more program modules, such as a word processor application 120 and other applications described below. Word processor application 120 operates to provide functionality for creating, editing, and processing electronic documents.

  In accordance with one embodiment of the present invention, the word processor application 120 includes the WORD program of MICROSOFT Corporation. However, it should be understood that other manufacturer's word processor application programs may be used. The illustration of the word processing application is only an example and is not intended to limit other types of applications that can create and work with documents. Other application programs capable of processing various forms of content (eg, text, images, pictures, etc.) such as spreadsheet application programs, database application programs, slide presentation application programs, drawing or computer aided application programs 106 is equally applicable. An example application program 106 that creates and works with various different types of documents includes OFFICE from MICROSOFT Corporation.

  Embodiments can be implemented as a computer process, a computing system, or as an article of manufacture such as a computer program product or computer readable medium. The computer program product can be a computer storage medium that is readable by a computer system and that encodes a computer program of instructions for executing a computer process. A computer program product can also be a propagated signal on a carrier wave that is readable by a computing system and that encodes a computer program of instructions for executing a computer process.

  Throughout the specification and claims, the following terms have the meanings associated with the specification unless otherwise indicated by the context of the terms.

  The term “data” refers to the document's surface-level or presentation-level information, such as words, sentences, paragraphs, as well as supplemental information, such as a word processing document, refers to that document, and uses metadata May point. This information is often extensive and is not likely to be exposed on the presentation layer of the document.

  The term “presentation” refers to the visible portion of a document, such as text and layout that will appear when the document is printed.

  The term “tag” refers to a character inserted in a document that delimits elements in the XML document. Each element generally includes two tags: a start tag and an end tag. It is possible to 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 in a document that specifies how parts of the document are interpreted by an application. In a word processor file, the markup language specifies how the text is formatted or laid out.

  The term “element” refers to the basic unit of an XML document. Elements can include attributes, other elements, text, and other content areas for XML documents.

  The term “building block” refers to a bounded, potentially labeled area in a document that acts as a container for a particular type of content entered by a user. .

  The term “data binding, data mapping, and data field” refers to a property on the composition unit that determines the XPath to the XML DOM stored in the document in which the content of the composition unit is to be stored.

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

  The term “attribute” refers to an additional property that is set to a specific value and associated with the element. An element can have any number of attribute settings associated with it, including none. Attributes are used to associate additional information with elements that do not contain additional elements or are processed as text nodes.

  “XPath” is an operator that uses a pattern expression to identify a node in an XML document. The XPath pattern is a list of child element names separated by slashes that describe the path through the XML document. The pattern “selects” elements that match the path.

  The term “XML data store or data store” refers to a container in a document, such as a word processor document, spreadsheet document, slide presentation document, etc., stored in the document while the file is open (eg, in XML format). Provide access to store and modify data. The XML data store is further defined below in connection with FIG.

  FIG. 2 is a block diagram illustrating the relationship between one or more client applications, one or more data stores and data store contents. Generally speaking, one or more data stores are connected to the main presentation storage in a document to store, correlate, and enable any data associated with a computer-generated document. Are maintained separately. Data for structuring information associated with a document, such as document metadata, is maintained in a data store where relationships between different data are maintained. The data store exposes an application programming interface (API) to various data in the data store so that various applications can access and interact with one or more of the data. As used herein, the terms “data consumer”, “application”, and “process” can be used interchangeably unless the context clearly dictates otherwise.

  The data can be structured according to a markup language such as Extensible Markup Language (XML). 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 can contain any number of any data items, eg metadata, structured according to Extensible Markup Language (XML). Thus, the document solution provider stores any metadata as XML with a given document, when the data is removed or loaded into the data store, and / or the document is opened / edited / saved by the user The information can be processed by a given solution that accesses the data when an event occurs, such as when an event occurs.

  Also, data in XML form can be programmatically accessed while the document is being edited. According to one embodiment, a standard mechanism, well known to solution developers, is provided that allows data to be accessed and modified programmatically while the document is open. This programmatic access is similar to a standard XML interface. Programmatic access to data is achieved through an application programming interface to one or more editing client applications (eg, document editing or creation applications, and / or third party application add-in solutions, etc.). Thus, multiple client applications can access and edit the same document data, and any conflicting changes to the given data are resolved. “Side effect” can be added for any given change (eg, changing the stock symbol to “MSFT” in response to setting the company name to “Microsoft”). Furthermore, changes to the data and any associated side effects can be “bunched” by the data store so that undoing one or more changes will reverse all relevant changes. This puts a burden on development from the solution itself to ensure that the solution covers all changes when the user starts undoing the original change from the document surface, for example by pressing the Undo command. Helps in removal.

  Use standard XML schema (XSD) to define the content of any custom XML data associated with the document metadata to ensure that the XML data applied to the document data is valid be able to. These schemas can be attached to any instance of XML data stored in the document, and the data store will invalidate the XML structure of that data (ie, the XML tag, not the contents of the XML tag). You will not allow any changes to the XML data that will be. This ensures that the solution developer can attach specific XML metadata to the document, and regardless of which data consumer (eg, add-in) is used to modify the XML data Helping to ensure that the data remains structurally “correct” according to the associated schema.

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

  Data store 208 is a document data repository for storing 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, multiple data stores can be used. Metadata 1 225 (structured data item) may include XML structure data and associated data for the first metadata associated with the document. For example, the metadata 1 225 may include XML structure data (eg, date tags, name tags, etc.) that lists the author of the document, the document creation date, the last modification / save date of the document, etc. Metadata 2 230 (structured data item) can include XML structure data (tags) and associated data representing second metadata associated with the document. Metadata 1 and metadata 2 are merely examples and are not intended to limit the various different types of data that can be maintained in the data store 208 in association with a given document. I want you to understand. For example, as described herein, any data can be structured and added to a document by one or more software applications if desired by a solution provider or a user who can access the document data. be able to.

  Optionally, schema files 240, 245 are stored in data store 208 to indicate the syntax and validation rules associated with Extensible Markup Language (XML) data applied to each data 225, 230. It may be attached to each data. XML schema files provide a method for describing and validating data in an XML environment. The schema file describes which XML markup data, including elements and attributes, is used to describe the content in the XML document, and the schema file describes where each element is allowed and what type of content is the element XML markup syntax is defined, including what is allowed in and what elements can appear in other elements. The use of schema files ensures that documents (or individual data in this case) are structured in a consistent and predictable way. Schema files 240, 245 can be created by the user and are generally supported by an associated markup language such as XML.

  With document organization, the data store provides the ability to "guarantee" the structural validity of a document by rejecting any violations of a given schema file at the data store level. Can do. According to one embodiment, the data store 208 may use a schema to validate XML structures added to the given data or changes made to the given data against the associated schema file. A validation module 260 is used. For example, if a document creator or editor makes changes to the given data, eg, metadata 1, in the XML structure, and the editor adds or removes the given XML tag, the data store 208 is schema-validated. A verification module will be used to check XML structure changes against the associated schema file to ensure the validity of the changes. If the change is not valid, an error may be generated for the editor. As can be seen, such control of XML structure applied to a given data allows structural consistency and particularly important to allow clients and third-party applications to interact with relevant data. Predictability is provided.

  The data store 208 is via a client application 205 (eg, a word processing application, a spreadsheet application, a slide presentation application, etc.) and an object model (OM) of each application 205, 210, 215 by a third party application 210, 215. One or more application programming interfaces (APIs) 270 that can be accessed are provided. These APIs allow client and third party applications to load any existing XML file into the data store 208 of a given document, so the data is now part of that document ( Ensure that it moves within the document during its lifetime (eg, via open / edit / save / rename, etc.) or until the data is deleted from the data store. According to one embodiment, the data in the data store can be used in its XML format even when the source application for the given data 225, 230 is closed or otherwise unavailable. It is. That is, given data 225, 230 can be accessed by other applications (other than the source application) via API 270. As described below, the API also allows clients and third party applications to make changes to XML markup data applied to data items 225, 230.

  After the XML data 225, 230 is loaded into the data store to be associated with the document 220, the same methods as the existing XML editing interface are used to leverage the developer's existing knowledge about the XML programming standard. A data store interface designed to provide can be used to operate as a standard XML. This allows the user to add elements and attributes, remove elements and attributes, and change existing element / attribute values for XML data added to the data store for a document. As well as reading the value of any existing portion of the associated XML tree. Using these XML standard operations, the solution can store complex structured metadata with documents without the previous constraints on data length / size or data structure. This allows the XML data store to be used for solutions that are significantly more structured than traditional solutions. For example, the third-party application 215 is written to locate and extract the document author's name and document creation date from several documents by reading the metadata 1 225 added to the data store 208 for each document. May be. An example third-party application may be an application programmed to create a list of document author names and document creation dates for all documents created by a given organization. According to an embodiment of the present invention, a third party application can use the XML structure applied to metadata 1 to efficiently locate and extract the desired data. For example, a third-party application parses the XML structure of the metadata 1 file to get the data associated with these tags, such as <docauthor> and <doccreationdate>, and to locate the XML tags for use May be described as follows. It should be understood that the foregoing is just one example of the many ways in which one or more applications can interact with structured data associated with a document via data store 208.

  In addition, the data store 208 has several API interfaces for the same data so that multiple applications 205, 210, 215 can function with individual XML data 220, 225, 230 (also known as store items). 270 is provided. For example, some solutions, such as client applications (eg, word processing applications) and third-party application solutions (eg, the applications described above) have the same set of document properties (eg, properties contained within a metadata 2 230 file). Can work with. Using the data store 208, each of these applications does not need to deal with the complexity of having multiple data consumers accessing the same data, and each application can send data via its own OM. Receive separate access to the desired XML data 230 via their own data store API interface 270 so that they can communicate with.

  In order to allow these multiple, data consuming applications 205, 210, 215 to access the same data, the data store 208 can be used when any part of the XML data is modified by another application. Each of these applications is notified so that a given application can respond to that change (from inside to its own process and from outside to other changes to the same data). When one application requests a change to a given data item, the request so that other applications can determine how to respond or whether to respond to the requested change Is automatically sent to all other applications. According to one embodiment, this “listens” for any part of the XML data that the application has an interface in such a way that a given application solution / program will only receive messages relating to its own logic. Is done by allowing each application to register. For example, one type of application 210 may wish to register to listen to all changes made to a given XML data in order to provide detailed business logic functionality to a third party solution. The type of application 215 only wants to listen to changes to one or two specific XML elements in the same data because its logic is not interested in changes to any other part of its XML data. There is no possibility.

  According to this embodiment, multiple applications 205, 210, 215 can access and edit the same document data, and any conflicting changes to the given data are resolved. For example, when one change by one application causes a side effect change by another application, a “side effect” for any given change can be added. For example, the first application 210 may convert a company name into a given stock symbol, if available, to compile a list of company stock symbols associated with the given document. May be tasked to extract these company names from one or more data items 225, 230 associated with the document. If the second application 215 changes, for example, the company name from “Company ABC” to “Company XYZ” and adds or changes the given company name in the given metadata, the first application Hearing this change, the list of stock symbols can be automatically updated to include stock symbols for “Company XYZ” instead of “Company ABC”. Furthermore, such changes and any associated side effects can be bundled by the data store 208, so that undoing one or more changes will reverse all relevant changes.

  FIG. 3 shows a system diagram illustrating interaction with an XML data store between an internal data consumer and an external data consumer. In the figure, the system 300 includes a data store 302, which includes a presentation layer 304, XML stores 1-N (306), each containing an error store and an undo store, a global change store 308, and an optional store. Global undo store 310, internal broker 312 coupled to internal data consumers 1-N 314, and external broker 316 coupled to external data consumers 1-N 318 are included.

  Using the XML data store 306, the document has the ability to accommodate any number of arbitrary data items (as long as each conforms to the standard XML syntax). Any metadata may be stored as XML in the document, and that information can be automatically shuttled when the document is opened / edited / saved by the user.

  As mentioned above, programmatic access to this data is accomplished via an API that can be used while the document is being edited, and this information is accessed while the document is open, and programmatically. Provides a standard mechanism that can be modified to be well known to solution developers. According to one embodiment, this programmatic access is designed to resemble a standard XML interface. Using this API, data can be added / removed while an application such as a word processing application is running, data can be put into store items (parts in the data store), Can be manipulated using standard XML constructs, the schema can be associated with any XML data in the data store, and the schema can be added / removed / modified after being associated with a data store item XML changes can be evented for any listening client. In the figure, the API comprises an external broker 316 that provides an interface for an external data consumer 318 and an internal broker 312 that provides an interface for any internal data consumer 314 that interacts with the data store 302.

  Operations on the data store 302 may be performed in real time. As discussed above, the data store 306 can contain one or more types of data. For example, one company may have one data store that it uses to store all the different types of data that it wants to store in a single data store, while another company You may want to store different types of data across different data stores.

  Data consumer 318 may register for events related to actions related to data store 306. For example, a data consumer can register to receive an event when any type of change is made to one or more data stores. Another data consumer can register for changes made to certain elements or sets of elements in the data store. Common events include loading the data store, adding to the data store, and deleting from the data store. When an event occurs, each registered data consumer can react to the change, while the state of the data store is maintained consistently. Data consumers often do not perform any action when changes are made. At other times, the data consumer will perform some action in response to the event. For example, the data consumer can make some other changes to the data store in response to the change, such as updating a header in the document in response to the title change. The data consumer can also perform some other operations that do not affect the document. For example, if a stock ticker symbol is inserted, the data consumer can retrieve the data associated with that stock symbol, but all of the retrieved data is displayed in the presentation layer in the document. It may not be. Data consumers can also reject changes. For example, if data consumer 1 receives an unacceptable change, the data consumer can return a flag to the broker to indicate that the change is not accepted. Whenever a change is not accepted, the change is reversed with any side effects so that the change is never made. Each XML store 306 can use its undo store to undo changes made. Alternatively, the global undo store 310 can be used to undo changes made across data stores. Imagine that there are three data consumers interested in what happens to a document property, and as a result, each of these data consumers has registered to receive events related to that property change. View. When changes are made, the data store determines each registered data consumer and notifies each of them in a predetermined order. Each data consumer can in turn perform some action in response to the change. If any of the changes or changes made by a data consumer registered as a result of that change are not accepted by any one of the data consumers, all of the changes related to the first change are revoked .

  The external broker application programming interface layer 316 provides access to the data store 302 by the external data consumer 318 and allows third party clients to interact with the data store 302 such that the internal data consumer associated with that application interacts with the data store. Make it possible to do. Each XML data store 306 in the data store 302 comprises a unique ID for identification. This helps in locating the XML data store 306.

  At any point, the data consumer can add a schema that is used to validate the data in the data store. Now if there is other third-party code that suddenly appears and tries to modify the data, the first thing the data store does is determine whether the change makes sense for the provided schema . After the schema is attached, the broker becomes a validation object.

  The data store can also receive multiple elements at once. Providing data (XML) as one specific stream may help satisfy the schema in some situations. For example, the attached schema states that if stock data exists, it must have at least two companies. If stock data is added one by one, it will not be valid.

  A single pass is used to validate the data. Rather than creating two paths where changes can be made to the data store, validation is performed before the data is passed 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 the data store. When reading the routine considerations presented herein, the logical operations of the various embodiments are (1) a sequence of operations performed by a computer, or as a program module operating on a computing system, and / or Or (2) It should be understood that it is implemented as an interconnected machine logic circuit or circuit module within a computing system. Implementation is a matter of choice due to the performance requirements of the computing system implementing the invention. Accordingly, the logical operations illustrated and making up the embodiments described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, operations, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof.

  FIG. 4 shows a process for handling events related to the data store. In general, when a data store receives a change request from a data consumer, the change is sent to all of the registered data consumers and the data consumer rejects the change or as a result of the change. Allows to request side effects (other XML changes).

  After the start operation, the process proceeds to operation 410 where the data consumer registers for any event that it is interested in receiving. Those events may relate to adding data to the data store, removing data from the data store, making changes to the data in the data store, and so on. An event may be tied to a global change or a specific change to an element stored in one or more of the data stores. For example, one data consumer may want to know when any changes have been made, while another client may only be interested in changes to one particular value in the data store. There is sex.

  Moving to decision operation 420, a determination is made as to whether an event has occurred. Events relate to changes to the data store. For example, as discussed above, an event may include adding, removing, or making some other change to the data store. For example, the change may be adding a node to the data store. When the event has not occurred, the process returns to decision operation 420. When the event occurs, the process proceeds to operation 430.

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

  Moving 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. Based on the response, it is determined whether the change will be delivered to the data store.

  Moving to decision operation 450, a determination is made as to whether any of the data consumers have rejected changes to the data store. When a change is rejected by any of the data consumers, the process moves to block 460 and any changes made in response to the change are reversed as if no change was made.

  When all of the notified clients have accepted the change, the process proceeds to operation 470 and optionally the change is validated, and then the process proceeds to operation 480 where the change is passed to the appropriate data store.

  The original data consumer that initiated the change then receives a notification that the change has been accepted (operation 490). The process then moves to the end block and returns to processing other actions.

  FIG. 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, and those clients reject the change, or as a result of the change, side effects ( Other XML changes) can be requested. For example, a client may be notified about changes to one item in the data store, and as a result of that change, the data consumer makes another change to the data store. When a change is requested as a side effect, the process is slightly different from the process shown in FIG.

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

  Moving to operation 520, this side effect change is queued but not executed. In other words, the side effect change is not performed immediately in the data store. Based on this, alternative forms of events include:

  Moving to decision operation 530, a determination is made as to whether any of the data consumers have rejected the original change to the data store.

  When a change is rejected by any of the data consumers, the process moves to block 540 where any changes made in response to that change, and any side effect changes that are queued, are changed. It will be reversed as if it were not.

  When the client accepts the original change, the process proceeds to operation 550 and optionally the change is validated, then the process proceeds to operation 560 where the original change is passed to the appropriate data store.

  The process then proceeds to operation 570 where side effect changes are performed one at a time in the data store. Each side effect change may then be accepted or rejected by any of the registered clients. When any of the side effect changes are rejected, all of the changes made are reversed as if none of the changes were made.

  The process then moves to the end block and returns to processing other actions.

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

  The first example shows adding a stream to the data store.

  The second example shows locating the data store.

  The third example shows adding a subtree to the data store.

  According to one embodiment, the following are exemplary functions associated with this API.

Events on CustomXMLNode
Events can occur on CustomXMLNode as well as at document level only.

  Parameters: NewNode: CustomXMLNode object corresponding to the node just added to CustomXMLNode. Note: This node can have children (if the subtree was just added to the document). InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is about to be added to the current document. If this add operation involves adding a sub-tree of the XML document within CustomXMLNode, this event is raised once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

  Parameters: OldNode: CustomXMLNode object corresponding to the node just removed from CustomXMLPart. Note 1: This node can have children (if the subtree is being removed from the document). Note 2: This node is a “disconnected” node in that it can be queried down from the node but cannot go up and appears to exist alone (ie, a document with the same OwnerStream) Element). OldParentNode: A CustomXMLNode object corresponding to the previous parent node of OldNode. OldNextSibling: A CustomXMLNode object corresponding to the previous next sibling of OldNode. InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is deleted from the current item in the data store. If this delete operation involves a subtree of an XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

  Parameters: OldNode: CustomXMLNode object corresponding to the node just removed from CustomXMLPart. Note 1: This node can have children (if the subtree is being removed from the document). Note 2: This node is a “disconnected” node in that it can be queried down from the node but cannot go up and appears to exist alone (ie, a document with the same OwnerStream) Element). NewNode: CustomXMLNode object corresponding to the node just added to CustomXMLPart. Note: This node can have children (if the subtree was just added to the document). InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is replaced in the data store. If this replace operation involves a subtree of an XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

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

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

  Parameters: Prefix: A string type representing a prefix to be added to the prefix mapping list. NamespaceURI: A string type that represents the namespace to assign to the newly added prefix.

  Allows developers to add custom namespace / prefix mappings to use when querying this item. If the prefix already exists in the manager, this overrides the meaning of the prefix, except when it is added / used internally by the data store, and then "This prefix is already used Error cannot be corrected "will be returned.

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

  Parameters: Index: A long integer that represents the index of the desired schema in the collection.

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

  Parameters: Prefix: A string type that represents a prefix in the prefix mapping list. Allows a developer to obtain a namespace corresponding to a specified prefix. Returns “” if the namespace is not assigned to the requested prefix.

  Parameters: NamespaceURI: A string type representing a namespace in the prefix mapping list.

  Allows a developer to obtain a prefix corresponding to a specified namespace. Returns “” if the prefix is not assigned to the requested namespace. If there are multiple prefixes specified in the namespace, the manager returns the first one that matches the supplied namespace.

  CustomXMLPrefixMapping: An object that represents a 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 validated or attached to a stream (some live collection), "This schema is currently in use because the schema collection is currently in use. It fails with the error message "Cannot delete".

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

  NamespaceURI As String: Returns the target namespace of this schema, and returns “” if nothing is specified by the XSD.

  Reload As Void: Reloads this schema from disk, which updates its location (if the SL has changed) and ensures that it is still a valid schema Will be reworked. If this is done for a schema in a collection that has already been validated or is bound to a stream (some live collection), "This schema is currently in use because the schema collection is currently in use. It fails with the error message "Cannot reload."

  CustomXMLSchemaCollection (): An object that represents a collection of schemas (attached / will be attached to the stream).

  Parameters: NamespaceURI: A string type that represents the namespace of the schema to be added to the collection. If the schema exists in the schema library (Schema Library), retrieve it. Alias: A string type that represents the alias of the schema to be added to the collection. If the alias exists in SL, find it using this argument. FileName: A string type that represents a location on disk where the schema can be found. If this parameter is specified, not only will the schema be added to the collection, but it will also be added to the SL. InstallForAllUsers: A Boolean that indicates whether the SL key should be written to HKLM (for all users) or HKCU (for current users only) when adding a schema to the schema library. Default is false (write to HKCU).

  This method allows the developer to add one or more schemas to the schema collection that is going to be added to the stream in the data store, as well as to the schema library. Can be called with the following set of parameters (in case of collision, try to use the parameters in the following order): That is, [NamespaceURI], [Alias], FileName, [InstallForAllUsers] (if a schema does not exist for that namespace, add the schema to the schema library). NamespaceURI only (looks up XSD from schema library). Alias only (look up XSD from schema library).

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

  Add an existing collection to the current collection. If namespaces collide 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 prevails become.

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

  Parameters: Index: Variant indicating the desired item in the collection. It can be either a string type that represents the target namespace of the desired schema, or a long integer type that represents the index of the desired schema in the collection.

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

  Parameters: Index: Long integer that represents 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 is valid. This is also when the includes are traversed for each schema in the collection and add them to the requested schema.

  CustomXMLParts (): A collection that represents a set of CustomXMLPart objects.

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

  Allows the user to add a new CustomXMLPart to the file. If the XML in the XML parameter is not eligible, it will fail with the error “Content must be valid and qualified XML to be added to this stream”. If the user provided a SchemaCollection, validate it (if not already validated). If there is a received MSXML parsing error, it is returned to the OM client and adding to the stream fails. Check if XML parameters can be loaded into DOM. If not, it fails and the error “Content must be valid and qualified XML to be added to this stream” is generated. Attach the schema collection to the DOM and attempt to validate the instance document. If it is not validated, it fails and returns the received XML parsing error to the OM client and does not add the stream to the collection.

  If the user does not provide a SchemaCollection, check whether the XML parameters can be loaded into the DOM. If not, it fails and the error “Content must be valid and qualified XML to be added to this stream” is generated. Examine the list of namespaces referenced in the XML file. Find these schemas from SL and infer a schema collection for them. Attempts to validate the resulting schema collection. If not validated, the stream is still added to the collection but is not associated with any schema collection and is therefore not validated. Attach the schema collection to the DOM and attempt to validate the instance document. If it is not validated, it fails and returns the received XML parsing error to the OM client and does not add the stream to the collection. If not validated, the stream is still added to the collection but is not associated with any schema collection and is therefore not validated. Providing an empty SchemaCollection is an explicit action taken to represent "never validate this stream".

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

  Parameters: Index: One of the following two types: a long integer type representing the index of the desired CustomXMLPart in the collection, or a string type representing the root namespace of the desired CustomXMLPart in the collection. Variant type that can. If multiple parts match this root namespace, the first match in index order will be returned.

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

  Parameters: ID: A string type containing the ID for the data store item to be returned from the collection.

  Allows the developer to grab that particular item from the data store using its ID. If there is no store item with this ID, Nothing is returned.

  Parameters: NamespaceURI: A string type representing the root namespace of the desired item from the data store collection.

  Returns all datastore items whose root namespace matches the requested entry. If there is no stream with this root namespace, an empty CustomXMLParts () collection is returned.

  Parameters: NewStream: A 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 is added with XML content (using the appropriate .Add method), this event will not occur until the item is occupied with this content.

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

  This event occurs whenever a stream is removed from the data store. If multiple streams are deleted, this event occurs once for each deleted stream. Also, this stream is flagged as “scheduled for deletion” so that read-only operations on it are valid (eg, querying nodes, checking values, etc.), but write operations are It fails with the error message "Cannot execute on the stream."

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

  Parameters: Name: A string type representing the base name of the node to be added to the XML DOM. Namespace: An optional string type that represents the namespace of the node to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, ignored otherwise. Parent: CustomXMLNode that represents the node under which this node should be added. When an attribute is added, the element to which the attribute is to be added is indicated. NextSibling: An optional CustomXMLNode that represents the node that should be the next sibling of the new node. If not specified, the node is added to the child end of the parent node. Ignored for adding msoXMLNodeAttribute type. If NextSibling is not a child of the parent, the error "This node cannot be added because the next sibling node is not a child of the parent node" is returned. NodeType: An optional msoCustomXMLNodeType that specifies the type of node to create. If not specified, msoCustomXMLNodeElement is assumed. NodeValue: An optional string type used to set the node value for nodes that allow text. This parameter is ignored if the node does not allow text.

  Generic method for adding an XML node to a data store item. A parent is required and NodeType defaults to msoXMLNodeElement. If the addition made is structurally invalid, it fails with the error message “This operation cannot be performed because it causes a structurally invalid data stream”. If the namespace is not in the schema reference collection, it fails and provides the error message "To add this element, you must first attach the schema to the data stream".

DocumentElement As CustomXMLNode
Get the root element of the stream. Returns Nothing if the stream is empty.

  Delete As Void: Deletes the current CustomXMLPart from the data store. If the user attempts to delete the core property part, it fails with "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.

  Parameters: FilePath: String object corresponding to a file on the user's machine (or network, etc.) from which the XML for this CustomXMLPart should be loaded.

  Allows template authors to populate CustomXMLPart from a pre-existing file on the machine. Returns true if load succeeds, fails if unsuccessful (including if structure enforcement is on and XML is structurally invalid, or if XML is not valid and / or eligible) Return false. After the DOM is loaded, it fails with "This DOM cannot be loaded twice".

  Parameters: XML: A string type object corresponding to XML to which this CustomXMLPart should be loaded together.

  Allows a template author to populate a CustomXMLPart from an XML string. Returns true if load succeeds, fails if unsuccessful (including if structure enforcement is on and XML is structurally invalid, or if XML is not valid and / or eligible) Return false. After the DOM is loaded, it fails with "This DOM cannot be loaded twice".

  NamespaceURI As String: Returns a string containing the complete namespace URI for the current CustomXMLPart root node. Returns “” if the stream is empty (created but no nodes added).

  SchemaCollection As CustomXMLSchemaCollection (): Get / set the CustomXMLSchemaCollection () collection that represents the set of schemas attached to this stream. If the user provided a SchemaCollection, validate it (if not already validated). If any parsing errors are received, return them to the client, failing to add to the stream, attach the schema collection to the DOM, and attempt to validate the instance document. If it is not validated, it fails and returns the received parsing error to the client and does not change the schema collection on the stream.

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

  Parameters: XPath: A string type containing an XPath expression to be evaluated against DOM. The prefix mapping for this XPath is retrieved from the associated namespace manager. If XPath is not resolved, it will pass whatever error is generated.

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

  Parameters: XPath: A string type containing an XPath expression to be evaluated against DOM. The prefix mapping for this XPath is retrieved from the associated namespace manager. If XPath is not resolved, it will pass whatever error is generated.

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

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

  Parameters: NewNode: CustomXMLNode object corresponding to the node just added to CustomXMLPart. Note: This node can have children (if the subtree was just added to the document). InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is about to be added to the current document. If this add operation involves adding a sub-tree of the XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

  Parameters: OldNode: CustomXMLNode object corresponding to the node just removed from CustomXMLPart. Note 1: This node can have children (if the subtree is being removed from the document). Note 2: This node is a “disconnected” node in that it can be queried down from the node but cannot go up and appears to exist alone (ie, a document with the same OwnerStream) Element). OldParentNode: A CustomXMLNode object corresponding to the previous parent node of OldNode. OldNextSibling: A CustomXMLNode object corresponding to the previous next sibling of OldNode. InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is deleted from the current item in the data store. If this delete operation involves a subtree of an XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

  Parameters: OldNode: CustomXMLNode object corresponding to the node just removed from CustomXMLPart. Note 1: This node can have children (if the subtree is being removed from the document). Note 2: This node is a “disconnected” node in that it can be queried down from the node but cannot go up and appears to exist alone (ie, a document with the same OwnerStream) Element). NewNode: CustomXMLNode object corresponding to the node just added to CustomXMLPart. Note: This node can have children (if the subtree was just added to the document). InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is replaced in the data store. If this replace operation involves a subtree of an XML document in CustomXMLPart, this event is raised once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

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

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

  Parameters: Index: A long integer that represents the index of the desired CustomXMLNode in the collection.

  This is the default member of the CustomXMLNodes object and returns the CustomXMLNode object corresponding to the requested item in the collection.

  Parameters: Name: An optional string type that represents the base name of the element to be added to the XML DOM. Namespace: An optional string type that represents the namespace of the element to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, ignored otherwise. NodeType: An optional msoCustomXMLNodeType that specifies the type of node to create. If not specified, msoCustomXMLNodeElement is assumed. NodeValue: An optional string type used to set the node value for nodes that allow text. This parameter is ignored if the node does not allow text.

  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 a child to a comment, processing instruction, or attribute". Also, if there is a case where the node to be added has an attribute that already exists, it is blocked. That is, "An attribute with the same name already exists on the current element."

  Parameters: XML: A string type representing a subtree to be added to the XML DOM. This XML must be a valid XML document (including namespace declaration, 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 eligible XML”.

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

  Attributes As CustomXMLNodes (): Returns a CustomXMLNodes collection that represents the attributes on the current element.

  BaseName As String: This is the default member of CustomXMLNode. If present in the DOM, returns the base name of the node without a namespace prefix.

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

  Delete As Void: Deletes the current node from the XML DOM (including all of its children, if any). If the deletion to be made is structurally invalid, it fails with the error message "This operation cannot be performed because it causes a structurally invalid DOM".

  FirstChild As CustomXMLNode: Returns a CustomXMLNode object corresponding to the first child element of the current node. Returns Nothing if the node has no element children (or is not itself of type msoCustomXMLNodeElement).

  HasChildNodes As Boolean: Returns a Boolean that is true if the current node has child element nodes, and false otherwise. This will return false if CustomXMLNode is not a NodeType msoCustomXMLNodeElement.

  Parameters: Name: A string type representing the base name of the element to be added to the XML DOM. Namespace: An optional string type that represents the namespace of the element to be added to the XML DOM. Required to add a node of type msoCustomXMLNodeElement or msoCustomXMLNodeAttribute, ignored otherwise. NodeType: An optional msoCustomXMLNodeType that specifies the type of node to create. If not specified, msoCustomXMLNodeElement is assumed. NodeValue: An optional string type used to set the node value for nodes that allow text. This parameter is ignored if the node does not allow text. NextSibling: An optional CustomXMLNode object that specifies the node to which the new XML element should be added to the tree before.

  Inserts a new child node into the tree at the specified location. If there is no BeforeNode when adding a node of type msoCustomXMLNodeElement, msoCustomXMLNodeComment, or msoCustomXMLNodeProcessingInstruction, the node is added to the end of the list. Ignored if added for the msoCustomXMLNodeAttribute type. If NextSibling is not a child of the context node, this 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 made is structurally invalid (and schema enforcement is turned on) with the error message "This operation cannot be performed because it causes a structurally invalid DOM" It will be a failure. Also, if there is a case where the node to be added has an attribute that already exists, it is blocked. That is, "An attribute with the same name already exists on the current element".

  Parameters: XML: A string type representing a subtree to be added to the XML DOM. This XML must be a valid XML document (including namespace declaration, 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 eligible XML”. NextSibling: An optional CustomXMLNode object that specifies the node to which the new XML element should be added to the tree before.

  Inserts the specified XML subtree into the child node set at the specified location. 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 made is structurally invalid, it fails with the error message "This operation cannot be performed because it causes a structurally invalid DOM".

  LastChild As CustomXMLNode: Returns a CustomXMLNode object corresponding to the last child element of the current node. Returns Nothing if the node has no element children (or is not itself of type msoCustomXMLNodeElement).

  Returns a string type corresponding to the current node namespace. If the node is of the msoCustomXMLNodeComment msoCustomXMLNodeProcessingInstruction type, “” is returned.

  NextSibling As CustomXMLNode: Returns the sibling node (element, comment, or processing instruction) next to the current node. Returns Nothing if the node is the last sibling at that level.

  NodeType As msoCustomXMLNodeType: Returns an msoCustomXMLNodeType constant representing the current node type.

  NodeValue As String: Get / set the text inside a node that contains only text (ie, text nodes, comments, processing instructions, attributes). For elements, it fails with "Cannot set NodeValue parameter for element node".

  OwnerDocument As Variant: Returns a Document / Workbook / Presentation object representing 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. Returns Nothing if the node is the first sibling at that level.

  ParentNode As CustomXMLNode: Returns the parent element node of the current node. Returns Nothing if the node is at the root level.

  Parameters: Child: CustomXMLNode object representing the child node of the context node to be deleted. 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 a child of the current element".

  Removes the specified child node from the stream. If the resulting DOM is structurally invalid, it fails with the error message “This operation cannot be performed because it causes a structurally invalid DOM”.

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

  Removes the specified child node (and its subtree) from the stream and replaces it with the specified node in 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 made is structurally invalid, it fails with the error message "This operation cannot be performed because it causes a structurally invalid DOM". Also, if there is a case where the node to be added has an attribute that already exists, it is blocked. That is, "An attribute with the same name already exists on the current element."

  Parameters: OldNode: CustomXMLNode representing the child node to be replaced. XML: A string type that represents a subtree to add to the XML DOM. This XML must be a valid XML document (including namespace declaration, 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 eligible XML”.

  Removes the specified child node (and its subtree) from the stream and replaces it with the specified XML subtree in 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 made is structurally invalid, it fails with the error message "This operation cannot be performed because it causes a structurally invalid DOM".

  Parameters: XPath: A string type containing an XPath expression to be evaluated against DOM. The prefix mapping for this XPath is taken from the NamespaceManager property. If the XPath is not resolved, it passes through whatever error exists (according to the method for today's Document object with embedded XML).

  This method allows the developer to retrieve a set of nodes from within the data store item.

  Parameters: XPath: A string type containing an XPath expression to be evaluated against DOM. The prefix mapping for this XPath is taken from the NamespaceManager property. If the XPath is not resolved, it passes through whatever error exists (according to the method for today's Document object with embedded XML).

  This method allows the developer to get back a single node from within the data store item.

  Text As String: Get / set the text for the current node. Unlike MSXML, setting this for a node replaces that node's content with the specified string-for example, on a non-leaf element <foo> where the content of foo looks like this: Set it to "test".

  Although not a failure, the message will be different for the data store internally and for the client of the data store externally. If the replacement made is structurally invalid, it fails with the error message "This operation cannot be performed because it causes a structurally invalid DOM".

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

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

New Enums:
msoCustomXMLDataNodeType represents the type of XML node that can be used. msoCustomXMLNodeAttribute represents an XML attribute node. msoCustomXMLNodeCData represents a CDATA node. msoCustomXMLNodeComment represents an XML comment node. msoCustomXMLNodeDocument represents an XML document (/) node. msoCustomXMLNodeElement represents an XML element node. msoCustomXMLNodeProcessingInstruction represents an XML processing instruction node. msoCustomXMLNodeText represents a text node.

  Parameters: Child: CustomXMLNode object representing the child node of the context node to be deleted. 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 a child of the current element". Name: A string type representing the base name of the element to be added to the XML DOM. Namespace: An optional string type that represents the namespace of the element to be added to the XML DOM. Required to add a node of type msoXMLNodeElement or msoXMLNodeAttribute, ignored otherwise. NodeType: An optional msoXMLNodeType that specifies the type of node to create. If not specified, msoXMLNodeElement is assumed. NodeValue: An optional string type used to set the node value for nodes that allow text. This parameter is ignored if the node does not allow text.

  Removes the specified child node (and its subtree) from the stream and replaces it with the specified node in the same location. If the delete that is made is structurally invalid (and schema enforcement is turned on) with the error message “This operation cannot be performed because it causes a structurally invalid DOM” It will be a failure.

  XMLNamespace: an object that represents a single, unique namespace in a schema library (Schema Library).

  Parameters: CustomXMLPart: A CustomXMLPart object for the desired stream, or a variant type that can be the index of that stream in the CustomXMLParts collection.

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

  XMLSchemaReference: An object that represents a single, unique namespace referenced in the current document.

  Delete () As Void: Removes the namespace-and all elements in that namespace-from CustomXMLPart. However, in this case, the data store can reject this operation because structural schema enforcement is enabled and removing these elements results in a structurally invalid DOM. In this case, it will fail with the error “This operation cannot be performed while schema enforcement is enabled because the resulting stream is structurally invalid”.

  Parameters: Name: A string type representing the base name of the element to be added to the XML DOM. Namespace: An optional string type that represents the namespace of the element to be added to the XML DOM. Required to add a node of type msoXMLNodeElement or msoXMLNodeAttribute, ignored otherwise. Parent: An optional CustomXMLNode that represents the node under which this node should be added. When called from the CustomXMLNodes collection returned by the .Attributes property, it is assumed to be the parent node of the attribute. If called at any other time, this parameter is specified or returns the error "You must specify a 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, the node is added to the child end of the parent node. Ignored for adding msoXMLNodeAttribute type. If NextSibling is not a child of the parent, the error "This node cannot be added because the next sibling node is not a child of the parent node" is returned. NodeType: An optional msoXMLNodeType that specifies the type of node to create. If not specified, it is assumed to be msoXMLNodeElement unless called from the .Attributes property, in which case it is assumed to be msoXMLNodeAttribute. NodeValue: An optional string type used to set the node value for nodes that allow text. This parameter is ignored if the node does not allow text.

  Generic method for adding an XML node to a data store item. When called from the CustomXMLNodes object returned by the .Attributes property, Parent has the default for its parent node and NodeType has the default for msoXMLNodeAttribute. In all other cases, Parent is required and NodeType defaults to msoXMLNodeElement. If the additions made are structurally invalid (and schema enforcement is turned on), “This operation causes a structurally invalid data stream, so schema enforcement is on. , "Cannot execute" error message. If the namespace is not in the schema reference collection, it fails with the error message "To add this element, you must first attach the schema to the data stream".

  CustomDataXMLSchemaReferences (): A collection that represents all of the unique namespaces identified within CustomXMLPart. Note: By default it occupies an entry for each namespace declared in the XML file.

  Parameters: NamespaceURI: A string containing the namespace defined by the schema to be added to the schema collection. Alias: A string type that contains an alias to write when adding this schema to the schema library. FileName: A string type containing the path to the schema that should be added to the schema library. InstallForAllUsers: A Boolean type that determines whether a schema library key should be added to HKCU (default) or HKLM.

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

  EnforceStructure As Boolean: Gets and sets a Boolean that corresponds to whether the data store should impose structural validity on the associated CustomXMLPart according to its schema. If the user tries to set this property to true while the CustomXMLPart content is not valid, then "Unable to turn on schema enforcement while the content of this data stream is structurally invalid" Is returned.

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

  Parameters: Index: One of the following two types: a long integer type that represents the index of the desired CustomDataXMLSchemaReference in the collection, and a string type that represents the namespace of the desired CustomDataXMLSchemaReference in the collection. Variant type that can

  This is the default number of CustomDataXMLSchemaReferences objects and 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. Errors are reported on individual nodes (see ValidationStatus property).

  Parameters: NewCustomXMLNode: CustomXMLNode object corresponding to the node just added to CustomXMLPart. Note: This node can have children (if the subtree was just added to the document). InUndoRedo: A Boolean that returns true if the node was added by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is about to be added to the current document. If this add operation involves adding a sub-tree of the XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event.

  Parameters: OldCustomXMLNode: CustomXMLNode object corresponding to the node to be removed from 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 by the user as part of an Undo / Redo action and false otherwise.

  This event occurs whenever an XML node is deleted from the current item in the data store. If this delete operation involves a subtree of an XML document in CustomXMLPart, raise this event once for the highest node in the change. This event occurs once for each change messaged to the data store, so that the side effects of the change represented by this event also trigger that event. If the event handler attempts to modify anything under this node, it fails with the error message "This node is about to be deleted, so this change is not allowed".

  The above specifications, examples and data fully describe the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

1 is a diagram of an example computing architecture for a computer. FIG. 3 is a block diagram illustrating a relationship between one or more client applications and one or more data stores and data store contents. FIG. 2 is a system diagram illustrating an interaction with an XML data store between an internal data consumer and an external data consumer. FIG. 6 is a diagram of a process for handling events associated with a data store. FIG. 4 is a diagram of a process for handling an event that includes a side effect, according to an aspect of the invention.

Claims (18)

A method for managing data associated with a computer-generated document comprising:
Storing structured data items associated with the document in a data store maintained separately from the document data for the document ;
Here, the document data defines a main presentation for displaying the document, the structured data item is expressed in an extensible markup language, and the structured data item is metadata for the document. The structured data item remains associated with the document until the structured data item is removed from the data store;
The structure such that an application programming interface (API) is exposed to the plurality of data consuming applications to allow programmatic access to the structured data item by each of a plurality of different data consuming applications. The process of formatting the data
Here, while the document is open for editing and when the document is closed for editing , execution of the application programming interface (API) may cause the structured data item in the data store. The application programming interface (API) that provides the ability to access the structured data item by the plurality of data consuming applications, wherein the plurality of data consuming applications are the same at the same time Allowing access to structured data items, wherein the application programming interface (API) allows any of the plurality of data consuming applications to It makes it possible to store the structured data items within,
Registering with the plurality of data consuming applications for notification of changes;
Determining when a change has been made to one of the structured data items using the application programming interface (API);
Notifying the registered data consuming application of the change when a change is made;
Querying a side effect change by one of the plurality of data consuming applications in response to the notification of the change;
Here, the side effect change is generated based on data related to the notified change,
Notifying the registered data consuming application of the side effect change;
A method characterized by comprising: Reversing the change when one of the registered data consuming applications rejects the change;
The method of claim 1 , further comprising: delivering each change to the data store when each of the registered data consuming applications accepts the change. Associating the structured data item with an XML schema file that is used to validate the structured data item using the application programming interface (API) before the change is passed to the data store; The method of claim 2 , further comprising : The application programming interface (API) provides functionality for registering to receive notifications about changes to the data store and change notifications for at least one of the changes to one or more of the structured data items. The method of claim 1 , wherein the changes include deletions, additions and modifications to at least one of the data store and the structured data item. The application programming interface (API) is claim 4 adds a node to the data store, remove a node from the data store, and providing an interface for node replacing in the data store The method described . The application programming interface (API) is claims, characterized in that for providing an interface for using the existing file processing said data store, processing the data store using a string of XML 4. The method according to 4 . Claim wherein the application programming interface (API) is to add the name space to look up the name space, and add the schema, delete the schema, and providing an interface to reload the schema 4. The method according to 4 . The application programming interface (API) adds a data stream, the data stream is removed, and add the subtree to remove subtree, acquires sibling next to the current node, the current node to obtain a node type The method of claim 4, further comprising providing an interface for obtaining previous siblings. The method of claim 4, wherein the application programming interface (API) provides an interface for obtaining node values and performing structure enforcement . A way to manage data associated with the document generated by a computer,
Structured data item associated with the document, and storing using data store,
Here, the structured data item is structured according to Extensible Markup Language (XML), the structured data item is metadata for the document, and the structured data item is the structured data item. Remains associated with the document until it is removed from the data store;
In order to allow programmatic access to the document and to the structured data items contained within the data store, an application programming interface (API) is exposed to a first data consuming application . Formatting the structured data;
While the document is being edited and when the document is closed so that the structured data is linked to the document and serves as metadata describing the characters of the document, Executing the application programming interface (API) to access the structured data item, wherein the first data consuming application is added to the data store when registered. Receive notifications about changes,
Initiating a change to one of the data stores using the application programming interface (API);
Providing the notification to a second registered data consuming application regarding the change;
Querying a side effect change in response to a notification in the second registered data consuming application;
Determining when a response from the second registered data consuming application is a rejection, and reversing the change and the side effect change when the response is a rejection;
Determining when the first and second registered data consuming applications have accepted the change and side effect change , and wherein the first and second registered data consuming applications have received the change and side effect change . When accepted, optionally validating the changes and side effect changes using an XML schema file provided via an application programming interface (API) by one of the data consuming applications ;
Way, characterized in that it comprises the step of delivering the changes and side effects changes to one or more of the data store. Using the application programming interface (API) includes
To get a value for a node, add a node, delete a node, move a node, add a schema, delete a schema, reload a schema, add a namespace, remove a namespace 10. Symbol mounting method is characterized in that comprises the step of providing a programming interface further. A system for managing data associated with a computer-generated document,
A processor;
A memory connected to the processor;
A plurality of data consuming applications configured to execute on the processor;
A document data store configured to store the document in the memory ;
A data store coupled with the plurality of data consuming applications and configured to store structured data items associated with one or more of the documents;
Wherein the structured data item remains associated with the one or more documents until the structured data item is removed from the data store;
With
The data store is
An XML data store,
An API broker configured to interact with the plurality of data consuming applications ;
A change store configured to store changes associated with changes made to structured data items;
An undu store configured to reverse the changes made as a result of the changes made to the structured data item;
During the API broker, a programmatic link to link in the item also in the data store for the document to be provided to the data consuming application, the data consuming application, the document is open And when the document is closed, the programming interface (API) is configured to execute the programming interface (API) to access the structured data item in the data store, the data consuming application further comprising: A system configured to query a side effect change when an item in the data store for a document is changed . The data store is
Receiving changes to Extensible Markup Language (XML) markup data applied to the structured data item;
Reading an XML schema file associated with the structured data item targeted by the change to the XML markup data;
Determining whether the change to the XML markup data is valid according to the read XML schema file;
If the change to the XML markup data is not valid 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 is valid according to the read XML schema file when one or more of the claims 12 Symbol mounting system characterized in that it is further configured to deliver the changes to the XML store. Each of the XML data store, according to claim 12 Symbol mounting system is characterized in that comprises the undo store and a change store. The application programming interface (API) may provide an interface for adding a node to the data store, remove a node from the data store, replacing the nodes in the data store, to obtain the value from the Datastore 13. The system of claim 12, wherein: The application programming interface (API) is 15. Symbol mounting system adds a schema, remove the schema, and providing an interface to reload the schema. A computer program having instructions capable of executing the method according to any one of claims 1 to 11 by a computer. A computer-readable recording medium comprising the computer program according to claim 17.

Images