MXPA06000161A - An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture - Google Patents

An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture

Info

Publication number
MXPA06000161A
MXPA06000161A MXPA/A/2006/000161A MXPA06000161A MXPA06000161A MX PA06000161 A MXPA06000161 A MX PA06000161A MX PA06000161 A MXPA06000161 A MX PA06000161A MX PA06000161 A MXPA06000161 A MX PA06000161A
Authority
MX
Mexico
Prior art keywords
document
content
components
documents
user
Prior art date
Application number
MXPA/A/2006/000161A
Other languages
Spanish (es)
Inventor
Alex Krieger Michael
Cartine Becky
Davie Loren
Napolitan David
Smith Amy
Brown Kathie
c kelly Scott
Original Assignee
Brown Kathie
Cartine Becky
Davie Loren
Kelly Scott C
Alex Krieger Michael
Napolitan David
Smith Amy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brown Kathie, Cartine Becky, Davie Loren, Kelly Scott C, Alex Krieger Michael, Napolitan David, Smith Amy filed Critical Brown Kathie
Publication of MXPA06000161A publication Critical patent/MXPA06000161A/en

Links

Abstract

The present invention automates the publishing of financial, legal, and governmental documents and any other publications that are structured and require compliance with corporate or external standards and may share content elements. It gives users control in an always-on, familiar environmen

Description

AN AUTOMATED EDITORIAL SYSTEM THAT FACILITATES THE EDITION COLLABORATIVE AND RESPONSIBILITY THROUGH A ARCHITECTURE OF VIRTUAL DOCUMENTS FIELD OF THE INVENTION The present invention relates to the collaborative preparation, composition and editing of documents that form a set of closely related and similarly structured documents that can share content elements. The set / sets of documents require structural and content control to adapt to commercial rules and / or regulatory requirements and may require presentation simultaneously in different formats and media. The effort of document publication is sensitive in terms of time and cost.
BACKGROUND OF THE INVENTION The current mode for preparing documents up to now has been (1) a serial manufacturing mode and 2) a dependency on the availability of the data source that controls the publishing programs. The procedure also involves transferring customer data from your preparation system, such as Word, to another manufacturing system to compose and prepare for printing. In this procedure, the printer may introduce printing errors (PE, not billable to the customer), which must be separated from the alterations of the author (AA, billable) during the billing procedure. When a set of documents shares text or other elements, any changes to the elements must be spread across the entire set of documents, which often have different publication dates. The frequent manual solution is to distribute notes to editors responsible for individual documents that require changes. This method does not guarantee dissemination (due to other changes that may occur during the time between publication dates) and does not enforce the change procedure itself. Older electronic methods to deal with this problem, such as the library of repetitive elements, introduced into earlier trademark word processing systems, often imported the repetitive element into the document itself, a later more generalized method involving the use of language of Generalized Marking (SGML), an ISO international standard. SGML exposes a standard open method for writing a set of rules to form a group of documents that share the same general structure and content types. SGML introduced a method to store repetitive elements or recurring text and insert it by reference; the repetitive element could reside outside the document itself. However, the reference continued to be incorporated into the current of the document and the document had to identify the source of the reference of the repetitive element. There was not an efficient way to handle editing by fragments. A subsequent adaptation of SGML is the Extensible Markup Language (XML), also a method to describe the structure and elements of document content, this has gained acceptance in the World Wide Web (WWW). XML, like SGML, effectively separates the structure and content of the visual format. The challenge for the inventors was to develop a mechanism that effectively incorporated shared elements without integrating them into a continuous document. The use of the invention of XML solved the problem of asserting the structure and describing the content, and an additional separation, separation of the structure of the content, was executed using XML elements to indicate the content without containing it. The result is a virtual document.
SUMMARY OF THE INVENTION The present invention focuses on a system that handles documents as small reusable shared components, up to a paragraph level and frame cell. In the system, a user interface allows a user to generate a publication from these controlled version components with automated support. The present invention has many advantages over conventional editing methods. For example, the present invention reduces the time for publication because the precision and consistency it provides leads to a smaller amount of errors. Provides responsibility through the registration and documentation of all changes. Allows direct collaboration on the Internet. It also solves the problem of divided responsibilities for the content of the document, such as between the control of management numbers and the need for the legal department to control the declarations. In addition, any number of tests and alterations of the author can be produced without delays of time. Comments and distribution of tests can be executed electronically. The system also provides full-text search capabilities in a unified schema that can refer to all objects in the system. This includes tools to avoid damage to the components shared with other documents. The system provides flexible programming and also allows a user to work in advance without confusion in the type of version. Global changes are made automatically through the library. There is greater control over the management of the system due to the ability of an administrator to establish restricted work groups. The system described above can be applied in a variety of situations. For example: • when a group of documents shares a significant amount of content - by managing document components at the paragraph level, the components can be shared between documents at a granularity that maximizes efficiency and flexibility, in contrast to systems that only apply in large parts of content. • When the shared components need revision - the change has to be made only once.
The attributes of the component that capture the business and the control of the regulatory rules where the components appear, • When the documents must be adjusted to one or more regulatory environments - the system can store structural sketches and component versions for each environment. • When document preparation is a collaborative procedure - in situations involving multiple authors, such as textbook editing, authors can open the same book or section of a book for collaborative work in real time. The sections of the documents can be prepared by different working groups within a company. • When the documents of a company are assembled from the data provided by external companies - the creators of subcontracted parts of larger systems can provide and own portions of the documentation and each collaborator can work on the document simultaneously (instead of to assemble the entire document from fragments). • When documents must appear in many languages without delays - the system has a robust translation management system that ensures that revisions are translated by electronic notifications to translators when changes occur and each paragraph is linked to their other language and localization versions . • When the review procedure involves a number of external collaborators - comments from reviewers can be delivered electronically and entered into a tracking system that provides publishers with formal notification of comments up to a component level and reviewers can access to complete composition tests in the network. • When the content requires protection against unauthorized revisions - the system can establish ownership of the content up to a paragraph level. • When a company has an inventory of models that need documentation - the service and user manuals have similarities and differences in the models. • When companies want to publish personalized documents and not force their budgets - the system can easily integrate links with external databases to implement personalization and can produce urinals on high quality demand quickly and automatically. • When documents have rigorous deadlines and must be published simultaneously in several formats - the system can deliver complete composition tests, new on demand, in minutes. The system simultaneously delivers tests / originals in the formats demanded by the user's commercial needs. Some industries that are faced with these situations include financial and insurance services, large manufacturing businesses, textbook and newspaper publishing, government, national and transnational, legal publications, aircraft manufacturing, defense industries, regulated producers such as suppliers of energy, drugs and food, and software companies. As embodied in the invention, a publication is a document that (1) the client identifies as different from other publishable documents due to its subject matter, audience, purpose, etc .; that (2) must be adjusted to the corporate identity and business rules of a company; that (3) may be published in a conventionally distributed form such as print or Internet files; and that (4) may be repeated periodically in a recently published form. By definition, a publication has a property of language and only one (a publication in multiple languages has a unique set of languages). Any publication must conform to its type of publication, a formal definition of the generalized rules for the content of a publication, its order, and relationships with precursors / products. A group of related publications that share a certain amount of content and that are regulated by a discrete set of publication types is qualified as a publication set. For example, in the financial services industry, an information leaflet may have a type of publication, a shareholder report may have its own different type of publication, but may be part of the same set of publication of shareholder releases, because they share financial tables, disclosures, biographies of portfolio managers, etc. Because the invention creates virtual documents by using indicators for structural elements that in turn indicate the content, documents of different structural types can share the same content. Because the invention revolves around the automation of a publication, the working groups responsible for the different parts of the document can work on a virtual document simultaneously as shown in Figure 14. The content of the document can be created before a edition of the document itself. In the serial manufacturing model, there are frequent points in the program where collaborators must meet for approvals and work on group deliveries. In one embodiment of the invention, collaborators can approve the components of the documents for which they are responsible once their components have been finalized and notify other team members by e-mail. For example, most financial services companies assign data in a tabular form to a product management group by reviewing the required language and disclosures to a legal group, and descriptions of the investment policy and objectives for marketing and / or portfolio managers. These different types of content can be created at any time and, using the various filtering capabilities of the system, can be previously assigned to one or more documents. The system then allows diffused or collaborative responsibility for the content of a document, without having to make physical or electronic deliveries from one group to another. Figures 2ßa, 26b and 2ßc show a comparison between a prior art method and one embodiment of the method according to the invention. As is evident from the complexity of the document preparation shown in the prior art method, the applicants have recognized that a more simplified document preparation, such as that shown in Figure 26c, would be beneficial. By focusing on the needs of a client, the applicants also recognized that: a) the documents of their financial services and other clients were composed of components used globally in a set of documents, by a specific subset, or by a only document; b) performing the updates of shared components was a frequently inaccurate and time-consuming procedure; c) the client's documents were required to comply with the company's legal, regulatory and marketing requirements; d) there were severe penalties on customers for not publishing on time and even more severe penalties for not including the required material and legal disclosures; e) programs were hampered by timelines of the availability of the data source and external sources of fund accounting, legal services, or other third-party editorial contributions; f) the company staff was already preparing documents in a desktop environment for internal reviews before being sent to the composition service provider; g) important material was being typed redundantly by the service provider, introducing errors on a regular basis, even if the client's documents have been delivered for composition without those errors; h) the provider of the printing service required an exchange of material before the composition or changes to the pages could be initiated and a response time of 48 to 8 hours was required; and i) the serial nature of the ordinary procedure for producing tests and then carrying out the editing introduced time delays that negatively affected programming. This last factor is especially important as the deadline for printing approaches. In addition, financial services customers are required to deliver their documents electronically to government regulators in a particular format, and this delivery must be done simultaneously with the print preparation; this fact was another source of programming problems, since there was always a delay between the approval for printing and the delivery of the service provider of the format in a regulatory file, known as EDGAR II. The procedure for generating the EDGAR II files does not always derive from the same data source as print generation. The present invention addresses those issues by completely changing the workflow and the procedure of document preparation, review, editing, tracking changes, collecting comments, generating tests and tests with checked revisions, billing and creating the formats of printing and auxiliary files (such as EDGAR II) of the document. In one embodiment of the invention, the system allows important functions through its coding in XML. The use of this open-label standard allows simultaneous automated transformations in different data / file formats from a single data source, also known as view transformations. For example, financial services customers can receive composite test sheets in PDF, EDGAR II, and HTML format whenever a test is requested. XML also functions as filtering criteria in the evaluation of candidate components for inclusion in a publication. In one embodiment of the invention, the system introduces a new method for editing structured documents that preserves structural information but still allows for normal point-and-click editing. The concept of the structure bar is fully described in the Detailed Description and is shown in Figures 20 to 25. In one embodiment of the invention, the system is activated by the customer and directed by the customer. The operation in real time by the users means that the material is never passed in physical or in the form of a fax to a printing company, and there are no "response" spaces while the client expects the printer to deliver a proof. The client can generate a proof of the current status of the document at any time at no additional cost and with a minimum delay. The client's users are in full control of their work and procedure. No third-party service provider touches the component or data in the document; only the client. There is no concept of PE (printing errors), because data is never exchanged between manufacturing systems. The client, using the permissions system built in the Client Interface (Command Layer) (Figure 1), controls access to the system by establishing a detailed user permission list. The permissions control many aspects of the user interface including the system options presented to the viewer. The document and component data can not be read or, otherwise, unauthorized users can not access either the service provider or customer side. The security of the client's work is protected against interception, as would happen in the conventional delivery model between manufacturing systems. The system is both the source of the content and the producer of all the output formats, including the redacted pages; This is a perfect manufacturing system for publications. In one embodiment of the invention, the system operates in a World Wide Web environment over the Internet or using the same protocols in a dedicated Intranet. The cost advantage for the client is that they do not have to buy equipment or software and most of the clients have access to "continuous" Internet. Clients interact with the invention and its server over the network in real time. Users can access the system from any place and at any time of day, night or time zone, if they have a device with a standard browser and a connection to the Internet. In effect, the system never closes. The system does not have to rely on LAN connections and therefore is independent of the site or the equipment. In one embodiment of the invention, the system stores profile tables of all client documents and their publication programs. These tables also store other aspects of the subject matter of a client's documents, such as which products, services and / or topics are covered in a document (multiple levels). For example, many financial services companies combine mutual funds in an information booklet that covers certain types of funds (equity, bond, money market, balanced, etc.) or the product line. They can also print different information brochures for different kinds of shares of their funds - retail, institutional, private management, etc. These profiles tables, later analyzed as definitions of commercial objective and illustrated in figures 6 and 7, are part of the filtering system to apply specific components to certain documents. Profile tables can be reconfigured to meet a customer's needs, and the data can be reviewed. The "Commercial Rules" that evaluate the components for inclusion in documents are also configurable. All the components, including tables and footnotes, exist independently of particular documents, even those components that are contained in a single document. The components can be applied to any document and, if they are updated, the updated component will be automatically applied whenever it appears in a document (according to its effective and expiration dates). The system recognizes the concept of the equivalence of components in terms of language properties different from the text, combining written topics that adjust to different regulatory environments, and product terms and identifications (ID) in different market scenarios. Equivalence is the basis for automating natural language translations and regulatory filings that must conform to different national or state requirements. The tables and footnotes are handled by a specialized management module. This subsystem allows tables to be created as the data becomes available and, once complete, automatically applied to the appropriate active edition. Tables can also be created before starting the document in which they will be applied. Footnotes are also created and maintained as independent components; a specialized user interface (Ul) allows them to be easily applied to all tables or to cells and paragraphs of individual tables. The revision history for each component is tracked during its life, in all documents. The revision record displays a record for each revision, to which a user can attach explanatory notes; each record lists the date of the review, the user who made the review, the cover date of the document from which the user had access to the component, the test number where the review was made, the date of publication if applicable, and a display of marked revisions of the component text. The proofs of the documents can also be checked marked whenever the user generates a new test. (The review marked "blac lining" is a technical term to mark a test that can be reviewed to show where the revisions, deletions, and additions occurred from a previous state).
The system allows the electronic review and the elaboration of comments by experts who collaborate, inside and outside the client's organization. The reviewer comments on a special screen version of a generated test; they can attach comments to any component in the document. These comments will be tracked as matters that need resolution. The transformations of automated views are related to requests to generate a test or to publish a document. The formats such as EDGAR II have their origin in the same virtual document that generates the composition test. You can configure the formats that will be produced and the points at which they will occur during the procedure. Some actions trigger automatic notifications to users with permission to receive all those notifications. Automatic notifications from the system to the user include: PDF tests that are available, new editions of documents that are being started, tables that have been uploaded and the publication of documents that have been completed. Changes to the components are noted on the component screen by means of a special mark (the revision record will document the changes).
BRIEF DESCRIPTION OF THE FIGURES Figure 1 shows the ordinary architecture of the system and its guidance through the Client Interface (Command Layer) to the clients of the user according to an embodiment of the invention. Figure 2 shows several client communication protocols, all guided through the Client Interface (Command Layer) according to one embodiment of the invention. Figure 3 is a flow chart of an HTTP communication workflow according to one embodiment of the invention. Figure 4 is a flowchart of a SOAP (Simple Object Access Protocol) communication workflow according to one embodiment of the invention. Figure 5 shows the architecture that underlies the Virtual Documents and how they are composed according to one embodiment of the invention. Figure 6 shows the Management architecture of Commercial Objects that leads to the dynamic creation of complex Commercial Objects according to an embodiment of the invention. Figure 7 is a flow chart showing the exemplification of a Commercial Object according to an embodiment of the invention. Figure 8 shows the architecture of the Environment Management system that constructs the values of the environment of the document at any point in the document according to an embodiment of the invention. Figure 9 is a flowchart showing the construction and updating of the document environment by means of the Document Manager sub-system according to one embodiment of the invention. Figure 10 shows the architecture and relationships of the Auto Populator as it assembles the first edition of a Publication without referring to the map of elements of another Publication, according to one embodiment of the invention. Figure 11 is a flow diagram of a request to create a document that does not have a version published in the file, using DTD and rules only, according to one embodiment of the invention. Figure 12 shows the architecture and the relationships of the Auto Populator as it assembles a new edition based on a map of elements of the Base Edition "Foundation Edition" according to an embodiment of the invention. Figure 13 is a flow chart of a request to start a new edition of a published and archived document, the Base Edition, according to one embodiment of the invention. Figure 14 is a diagram of multiple work groups that work in the same document according to their area of responsibility according to one embodiment of the invention. Figure 15 shows the relationship between the elements and components at the time of modification of an element according to an embodiment of the invention. Fig. 16 is a flow chart showing the procedure for modifying a component. Figure 17 is a flowchart of a request to generate a test and the placement of the physical output document system to specific locations according to one embodiment of the invention. Figure 18 shows the ordinary architecture of the output system where the transformation engine retrieves the output specifications of an output format destination according to an embodiment of the invention. Figure 19 is a flow diagram of the actions at the time of a change of state to "Publish" the document according to an embodiment of the invention. Figure 20 shows the user interface screen for editing Active Editions "Active Editions", showing the hybrid tree navigation window "Hybrid Tree", the structure bar, and the WYSIWYG editing window, according to one embodiment of the invention. Figure 21 is a close view of the hybrid tree interface according to one embodiment of the invention. Figure 22 is an action diagram of the hybrid tree user showing four flow scenarios according to one embodiment of the invention. Figure 23 is an approach to the structure bar and the panel interface of the editor according to one embodiment of the invention. Figure 24 is a flow chart of various user actions that can be performed in the editor panel according to an embodiment of the invention. Fig. 25 is a flow chart of an active edit modification sequence according to one embodiment of the invention. Figures 26a, 26b and 26c show a comparison between a prior art method and one embodiment of the invention. Figures 27, 28 and 29 show the operation of the system from the point of view of an editing administrator, a contributing author / editor, and a reviewer according to one embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION The invention assembles and generates virtual editions of documents instead of a serial document file with integrated content. A document is a delimited collection of content intended to communicate a set of information to a specific set of recipients, either internal or external to an organization. In this definition, documents are not communicated transient day-to-day between colleagues, such as letters and memos. The documents, according to one embodiment of the invention, are presented in a certain formalized display or format that can be taken to a wider distribution. The documents may contain, but are not limited to, titles and other identifiers, expository text, graphic illustrations, diagrams, tables, internal references such as tables of contents and indexes, and other references such as footnotes or URL links. The system uses the concept of a structured document. A structured document can be described in terms of the order of its component parts, the hierarchical relationships, and the types of elements, apart from their content or literal meaning. There are two characteristics of many commercial and regulatory documents that can make them good candidates for structured treatment: 1) many documents, such as financial and legal documents, have instructional content, and 2) most business and government documents follow a consistent template or set of templates. Therefore, a set of sequence rules and content elements mentioned can be developed to meet an underlying standard whether that standard is formally expressed or implied by conventional practices. New documents and components can be constructed from the following rules. In one embodiment of the invention, the text and other components of the entire document set are separated into small and discrete constituent elements of a Publication Set. Basically each heading, sub-header, paragraph, table cell, footnote, list article, et al., Is identified as a component of the content with its own unique ID and can be referenced by elements of the document. In XML, an element is a demarcated part of the data in a document that has a declared name, content type, and location in a document. The elements may have related elements and may contain other elements (children's elements). The elements can also contain text information, entities in other annotations (such as illustrations), and a few other types of data. These low-level elements are the children of the components of a higher level that provide the elements of the text with a context within a document. These higher-level components can be identified by a descriptive profit margin, such as "Risk Factors" or "Contingent Liabilities". The context of an element is hierarchical, starting with the root element of the document itself. (The root element is the first element in a document, contains only elements, and is the relative of all other elements). The context of an element is part of its metadata and is an integral part of many procedures, such as the generation of documents and the narrowing of the field of text searches. (Metadata is the collection of data about an element, document, et al, apart from its content, such as time clocks, author, last update, type of publication, context, name of the display, etc.). The elements have rules, or requirements for the properties of the component, that are used to locate the specific components in the library, for example, the language must match the "Spanish". The invention stores the content components as discrete independent registers in independent tables of the document. An edition of a publication exists only in a virtual sense as a list of its elements. The elements point, each one, to a component ID, instead of containing the content directly. In this way, a piece can be shared by different elements located in different publications. The element map can be used to base a new publication on an existing one. The system manages content by maintaining a controlled version content library of the components. A component is a selection of content that has properties, which are key-value pairs and can describe the component in a meaningful way. The types of components may include, but are not limited to, text, footnote text, tables, an external data feed indicator, numeric, graphics, document fragments, content groups, etc. Each component is a separate entity in the content library. The components can be shared among multiple publications. New components can be added to the library and new components can be generated based on existing components. To keep the amount of data stored to a minimum, the system can check for the existence of duplicate components throughout the library. The components can be found using the system's unified search tool that can relate all the objects in the system, operating as a question system with search capabilities throughout the text. Searches can be executed while editing an active edition and also independently of a publication or edition. The components also carry values for: when they are effective, that is, when they can be used first in any active edition; and when, and in case they expire, that is, when they will no longer be part of any active edition. An audit record is created for each component that shows the creation date, the creator, the update date, the user of the update, the reasons for the revision, and the changes that are marked. Content groups can be built when there are multiple versions of a particular component; the versions can represent differences in the natural language, structuring of the words specific to a country, and structuring of the words focused on regulatory or commercial purposes, such as focusing on different market segments or covering different product models. These multiple versions may be related in a certain way. For example, each component may cover the same subject area, but may be written in a different language or encompass laws in different regions. Like any other component, a content group can have its own properties, but it does not have its own content. By contrast, content groups refer to other components. The content group will provide the content of one of its components, based on the evaluation of the system of its properties and the environment. The component versions can be strongly or weakly related to one another, expressed as having a strong or weak dependency on the primary element of the content group. The footnotes and tables form their own set of libraries. The tabular subject is kept as an independent library of the document and can be tested and edited separately from an active edition. The tables in the library can be applied to any document, with a single table command the data that must be obtained from third parties are accepted by the system using an agreement protocol that identifies the type of target table and the target document. The protocol also allows the san footnotes assigned in the data feed. Among other things, the system is operable to maintain a library of descriptions and footnotes. User interfaces allow easy assignment of a footnote to full tables or to individual table cells. Additional discrete libraries, such as inventory data, can be added to the system to suit the client's needs. The system is quite configurable for specific deployments. Deployments are system specific configurations supported by tables of objects, properties, rules and routines based on the needs of a user's organization. Some system behaviors can be configured as part of the deployment procedure. In broad terms, the client's business rules and data can generate distinctions between publications. Organizations can divide or establish ownership and responsibility for publications along division lines, product lines, target markets, national boundaries, areas of expertise, and similar considerations. This data can automate certain document authoring procedures, but to do this they have to be captured in a structured format. The query of structured data of this type can be used for tasks such as: determining subject matter of the publications, generating text and insertion points for URLs and live links, determining the appropriateness of a candidate component for inclusion in an Edition, and solve variables. To avoid the need to write customized programs for each client, the system has a generalized methodology to build this set of structured data; The data set can be questioned and integrated into many basic features of the system. The method can be configured in the deployment and has a user interface (Ul) to update the data. The system can use data from the specific client that it configures as commercial objects. Business objects must conform to one of the business object definitions that are built for each deployment after a formal schema. The definition includes a name for the type of object and a set of properties that can influence the content of the documents or that can be used for text generation or variable resolution. In an embodiment of the invention, each publication has an environment, or an association of commercial objects and publication attributes with the document. The environment can be associated on many levels, from a set of publication for testing, down to the component level. This environment is an accumulation of values that are inherited from the precursor object to the product. For example, if an active edition does not have a specific environment at the editing level, it would inherit from the parent, the publication, or from the progenitor of the latter, the publication set. Document objects are usually associated with usage rules, which evaluate environmental variables to take action, such as deciding which version of a component to include in a translated document. Rules are statements that refer to the business object and attribute values in the local environment. These consist of an antecedent and a consequence side. The antecedent side establishes a condition that must be evaluated to "true" or otherwise satisfy a value or comparative statement for the consequence actions to take place. The consequence side describes actions that must be undertaken for various evaluation results. For example, in the case of a translated document, the publication would have a value for language, inherited by the active edition, to establish the value of the property of the language with which all the components must coincide.
The system does not store documents as text streams but as indicators of elements in the structured document sketch. The elements in turn point to specific components. This organization facilitates non-repetitive storage and, most importantly, can achieve the automatic update of each publication that points to a revised component through its elements. Both the elements and the components have attributes and properties (respectively) that contain values that can be mapped for properties of active edition / specific publication according to the specific commercial rules of a client. The publications are the precursors of all the editions and are regulated by definitions of structured documents, called publication types in a modality of the invention. A type of publication is exemplified in memory as a document structure (figure 5); the structure of the document guides the AutoPopulator in the construction of editions (figure 11). Active editions, which are publications in a revisable state, are assembled from elements that refer to the components stored in the libraries. New active editions can be created from existing editions that reside in the publication file.
Each time a user opens an active edition, the system collects the list of elements, and through them, the components in their current state. The edition is assembled in the air, they are never stored for editing as a physical current. The edition exists as a serial entity only when it has been processed for external distribution, for example, as a test, EDGAR II file, placement in the network, document file published, etc. When the user starts a new edition of an existing publication (figure 13), the system can retrieve the latest edition, now considered the foundation edition to build the new edition. If any component has been updated since the foundation edition was archived, the update component is incorporated by reference. The part of the system called the document manager delegates the assembly of the document to the AutoPopulator, which reevaluates each element in the publication outline to ensure that it continues to conform to the current business rules and the publishing environment (Figure 13). If the objects and business rules have changed, a particular item may no longer belong to the publication. Instead of omitting the previously valid element, the system includes it with a soft state, which represents an error status.
All such soft inclusions must a) be removed from the edition by the user or b) have usage rules changed to the appropriate level to confirm their suitability before the issue is published. An example of a change in the rules of use that would invalidate previously legal elements is what arises when a financial services company divides its previously unitary information brochures into separate institutional and retail publications. Business objectives would be updated to reflect this change; therefore, the specific language of the institutional investor would no longer guarantee inclusion in a Retail Publication. For retail brochures, the system would no longer select a component with an "institutional" property. In the assembly procedure, the system evaluates the candidacy of the element for inclusion. A candidate element is an element that fully or partially satisfies the requirements for inclusion in a specific location in a particular document. The application is evaluated from the most specific to the most general, that is, from satisfying most of the rules-for-property coincidences to satisfying the least amount. Some component properties may require matches, such as language, and result in no candidate being held because no matches were found. The document assembly is controlled by the document's environment system based on multiple rules. These rules may include: a) The context of the element, which can be described in fully qualified terms (all its Precursors, starting at the Root Element) or in a relative form (ascending reference to a specific Precursor Element); the context property of the element must match the selected insertion point) XML-based rules can force the assembly of elements within an active edition by requiring specific structures. b) Rules and properties of the commercial object, evaluated in the local environment. The commercial data of specific deployment can dictate that specific content can be suitable or not suitable within the scope of an edition or active portion. c) Rules that evaluate the attribute values of the element or element and its precursors. The change in section of the properties of the environment can determine the suitability or non-adequacy of the content. A good example would be the establishment of a particular language within a part of an active edition. d) Rules that the components must be adjusted to certain qualitative properties to be suitable for inclusion in an active edition. e) Dynamic substitution of a component within a group of content by another, changing in certain variables of the environment. For example, the change between an English and French version of the same paragraph could be achieved with this mechanism. When the user starts the first edition of a new Publication (figure 13), the system can follow the methods described above to determine the candidacy of elements and components. If, as the case may be, no matching elements are found for a location, the system will insert position symbols for the elements required in the edition, following the formal structural rules of the publication type. In the end, the edition will consist of these structural position symbols. In the best of cases, the edition will consist of all the components qualified in context that exist in the library and of the position symbols for the required content that do not yet exist in the library. Underneath all this system lie the structural maps of the documents of a company developed by analysis of documents and / or formalized descriptions of a style and business rules of an organization. These structural maps follow a standardized syntax to describe documents in a generic way and can use Document Type Definitions (DTD) or an XML schema.
Structure Bar Edit Interface The invention focuses on the need for an editor that is user friendly for structured documents, especially the editing of XML documents. A major objection of many users regarding the previous methods for editing structured documents was that a) much knowledge of the marking principles was required to use the system easily or that b) such a small portion of the structure was deployed that it was often they made mistakes and only discovered when the dialing was validated. The solution adopted by the invention is 1) present the sketch of the document as a hybrid between an abstract tree of pure XML Schema and the actual content in the document in such a way that the user has a sense of the draft of the subject; and 2) Segregate the structural information contained in the marking of the document of the text of the document, which is presented as, and can be edited in a format that approximates the page already written (hereinafter referred to as "WYSIWYG"). The document editing system of this system includes a user interface 1 as shown in figure 20 which may consist of three main components: a hybrid tree 10 which is a collapsible tree which represents the structure of the document and it can be placed, although it is not limited to it, along the left side of the screen; an editor panel, the editor panel 30 where the WYSIWYG document that can be edited is displayed; and a structure bar 20 for graphically displaying the structural information about the content in the editor panel. The user interface may also include a toolbar 40 with several buttons and control icons. The hybrid tree can be used as a hierarchical navigation tool that represents the structure of a document, plus any "required and missing" structure as defined by the document specification. The hybrid tree as shown in the figure may consist of container nodes 11, component nodes 21, phantom nodes 31, multiple nodes 41 and error indicators 51. The container nodes 11 may represent structural sections of the document. Each container node 11 may contain a number of component nodes 21 that represent the individual content pieces in the document section. The hybrid tree can be used to select a portion of the document to edit by clicking either on a container node 11, or a component node 21 at which point the editor panel is populated with a WYSIWYG that provides the selected portion of the document. The selected node will remain highlighted indicating the section of the currently selected document. Phantom nodes 31 can represent portions of the document that do not yet exist, but are defined in the document specification. The multiple nodes 41 associated with a phantom node 31 may mean that the specification allows repeated instances of a component in the location. An error indicator 51 may be displayed together with a phantom node 31 to indicate that the specification requires the existence of a component or vessel at this location. A user can quickly correct this error by clicking on the phantom node 31, which allows the addition of an appropriate component. The system can also use a tool known as a structure bar as shown in Figure 23. The structure bar 20 describes the conceptual and organizational structure of an active edition 30 without affecting the WYSIWYG presentation of that active edition 30.
The structure bar 20 facilitates the manipulation of the structure of the active edition through reordering, movement, removal, and the insertion of components and sections. The structure bar 20 can also facilitate access / update of the metadata of a component and alert users about critical mission deficiencies in the active edition 30, as described in an XML schema. Although most word processors facilitate editing in a WYSIWYG environment, they do not convey information about the conceptual structure of a document and its rules. Additionally, there are many XML editors that facilitate the editing of structural documents, but lack the benefits of the WYSIWYG edition. The structure bar presents information that is based on non-visible structural elements (and therefore beyond the scope of WYSIWYG). The structure bar 20 allows the manipulation of these "groups in brackets" as a whole, unlike the code editors that use the bracket screens. The structure bar 20 executes a clean and complete integration of the structure and the content. This allows contributing content editors to work in the familiar point-and-click editing environment, protected from the complexities of structured content. Structural changes are made simply with the use of drag and drop insertion, reordering, and deletion of components. The structure bar 20 is presented in a vertical orientation, to the left of and adjacent to the presentation of the active edition 30 that is being audited. Each component presented on the right, has a corresponding handle 12 on the left. The handle 12 is an iconized representation of the component 82 that can allow direct manipulation of its associated component. A handle 12 is registered vertically with its corresponding component. To remove a component, its handle 12 is dragged to the garbage icon 72. To move a component, its handle 12 is dragged to the new destination in the active edition 30. Additionally, the containers 22 have representative handles in the structure bar. The containers 22 represent a section of the active edition. These are represented graphically as brackets that contain the handles of the components 82 that belong to the section. The container handle can be manipulated in the same way as those that represent standard components. The effects of moving / removing this handle are reflected in all the components contained. To remove a component 82 or container 22 from the active edition, its handle is dragged to the garbage icon 72. To move a component 82 or container 22 within the active edition 30, its handle is dragged to the desired destination in the editor panel. To insert a component 82 in the active edition, the insert icon 62 is dragged to the desired destination in the editor panel. The structure bar and the editor panel provide vital feedback during a component drag to insert / move. Although a component 82 or insert icon 62 is being dragged onto the active edit 30, a line can be drawn in the active edit 30 indicating the currently selected insertion point. Insertion lines can be traced in the space between the components that are closest to the mouse pointer. As these insertion lines are drawn, the container 22 containing the considered insertion point can be highlighted. When two adjacent components have different precursor vessels, the required number of insertion points may be available between these components, and for each one the appropriate precursor vessel may be highlighted. The movement of a mouse over a handle can highlight it and cause the tip of a tool to appear. This tool tip may contain basic metadata such as, but not limited to, the component's XML tag name and screen name. When double clicking on the handle, the complete metadata of the component can appear. This panel can display and allow a user to change the pertinent data to the component. As in the hybrid tree, the lack of component indicators 32 can be displayed to mark the locations of the active edition 30 where the content required by the specification is missing. Therefore, the user knows that an action must be taken to comply with the specification. Additional information regarding the nature of any error indicator is available by clicking on it by clicking on it. Figure 24 is a flow chart showing the possible actions that the user can execute while editing an active edition. The procedure starts in SlOO when a user must select one of many actions. For example, the user can choose to edit text on a screen in SllO. After which, the WYSIWYG view of the text can be edited in Slll. After the text is edited, a user can enter S112, causing an automatic window to open where a user can comment on the text edited in S113. The user submits the comment in S114 and the edited text and the comments are stored in a server as a new revision in S115 and the procedure ends in S170. In S120, a user can grab a handle and drag the associated component to a different place. The system then determines if the new location is an appropriate destination in S121. If the destination is appropriate, the component is moved to the new location and both the active edition and the structure bar display the component in the new location in S123. If the destination is not appropriate, then the component is not moved in S122. In S130, a user can grab a handle and drag it to the garbage icon. The associated component is removed from the active edition in S131 and a determination is made in S132 as to whether the component is required in the active edition. If not required, the procedure ends in S170. If the component is required, the component node is displayed as a phantom node in the hybrid tree at S133. The user may also wish to add a component to the active edition in S140 by grabbing the addition component icon and dragging the icon to a desired location within the active edition. In S141, an automatic window appears displaying all the appropriate components for the desired location for a user to select in S142. After a selection is made, the component is displayed in the active edition, the hybrid tree, and the structure bar in S143. If a user wishes to edit the metadata associated with a component, the user can double-click on the handle in S150. An automatic dialog box will appear in S151 where the user can edit the metadata associated with the component. A user may also wish to turn the structure on / off. If so, a user can click on the change button in the structure bar in S160. A determination is then made in S161 as to whether the structure bar is visible or not. If the structure bar is visible, the structure bar disappears in S162. If the structure bar is not visible, the structure bar appears in S163. Figure 25 shows an active edit modification sequence. In the sequence, a user modifies an active edit in S210 using the user interface of the editor. In S220, the system notifies the server about the previous modification. In S230, the server executes the modification and sends a snapshot of the modified active edition in S240. In S250, the editor displays the modified active edition. Figure 22 represents the possible actions that a user can execute on the hybrid tree. In S305, a user selects an action to execute. If a user clicks on a node in S310, the editor panel displays the node as the highest level and displays all the content in the node and its corresponding sub-nodes in the active edition in S311. If a user clicks on the maximize tab of an expandable node in S320, a determination is made as to whether the node is expanded in S321. If the node is not expanded, the node changes to an expanded view in S322. If the node is expanded, the node changes to a non-expanded view in S323. If a user clicks the names of the display screen in S330, the system determines whether the screen names are shown in S331. If the screen names are not displayed, then they appear in S332. If the screen names are displayed, then they disappear in S333. If a user clicks on the label names that are displayed in S340, the system determines whether the label names are shown in S341. If the label names are not displayed, then they appear in S342. If the label names are shown, then they disappear in S343.
Test status, review cycle, and subject tracking system After users have made a series of revisions, they may wish to review the formatted edition as it will be distributed. To do this, they can generate a test. In the present invention, a test is a static representation of the Active Edition at a point in time, such as pages written in a portable PDF format, an HTML file, etc. The user with privileges to perform tests can generate a test at any time when an edition is active; These are available in minutes so that they can be seen or used by the client, that is, in Network or a file transfer protocol (FTP) site or any other network protocol site. The tests can be prepared and circulated on these networks in PDF or other formats. You can also automatically generate a number of formats with each test. Tests with marked changes can be requested at any time, against any previous test, as part of the generation of a test. The generated tests, components, and published tests are archived for future access. The system of the present invention introduces the concept of a review cycle during which the reviewers can see a test. Reviewers, both within the company and outside the company, can provide comments electronically; Your comments can be appended at any point in a test and are tracked as issues. The users of the company can respond using the email or the same installation for the generation of integrated comments. During the review period, although reviewers are seeing a frozen test, users can continue to work on the active edition. Instead of waiting to initiate changes in response to comments from reviewers, you can work on those comments in an active and interactive way. All comments are entered into the subject tracking system. The issues track comments and questions regarding the content, dissemination and applicability of the component, versions, policies, etc. Matters may require a solution to publish an edition, to initiate the translation or localization of the components, or to establish broader policies that may affect multiple publications. Users can assign a priority level to an issue; each level determines the behavior of the system, depending on the configuration of the deployment. Issues can be assigned to members of the particular team and are tracked according to their state. Possible subject states are: open, modified, resolved, and deferred. Issues can be placed by users or can be automatically called by the system in defined situations, such as when a component has passed its expiration date without a new component available. Some issues, such as the lack of component translations, can be resolved by the system with appropriate actions by the users or other installation of the system.
Translation management The system can manage documents that are published in several languages or in multiple language editions. The design of the system also recognizes that documents may require additional individualization depending on a geographical environment, because regulatory and market requirements differ among national, state and provincial entities. Translation and localization are independent properties because there are often languages spoken in more than one sovereign entity. For example, documents in Switzerland, which has its own set of national regulatory requirements, often appear in German, French, Italian and English; to conform to Swiss law instead of French law, the French text in Switzerland may require a different wording than in France, and so on for each pairing of localization and language properties. The system can manage this situation thanks to its ability to store versions in groups of content, where the components can subscribe to other elements and where the components can have strong or weak dependencies on other elements. In the most frequent case, a publication was originally created in a single language. Because this is likely to be in the author's language (s), the original version often becomes the authorized or "Primary" version, and revisions to its components produce revisions to versions in other languages. This situation requires a strong dependence on the translated versions in the primary version; the other versions can "subscribe" to the original. Weak dependencies arise as the network expands further, especially when the versions diverge in language, location, or other property. A publication at the far end of the network may not depend on the first version but may be related to a second publication that derived from the authorized version; Such weak dependence on the original may not directly generate revisions to the publication at the end of the network. This publication may wish to receive notification of revision for the original authorized version but is not required to act in accordance with this notification.
The system can be configured to monitor the existence or non-existence of component versions in secondary languages with respect to the main language. Given the existence or creation of a publication in one of the secondary languages, the system can automatically assemble the components that do not have versions in that language for distribution to the translators or translation service. The exact mechanisms for exchange are configured in the deployment, but include: 1.- Structured transfer of files to / from translators. 2.- Dedicated navigation interface for real-time translation. 3.- Direct connectivity to a database for real time or batch translation. Each component that lacks a necessary translation has a point against it. When the translation is returned and it is loaded, the system changes the status of the issue to be resolved. The topic deployment screen can be configured in the deployment for the client's work procedures, either displaying each translation issue or sub-configuring by subject type. Version generation enables document publishing strategies apart from language translation and localization. It supports presentations in the same country for a master document with variations for local governments. For example, in the United States, insurance plans have state-specific compliance content. The product manuals may contain expanded sales information for consumers and trademark technical information for service organizations. The catalogs could be focused on specific markets.
Permissions The system allows an administrator to assign access / edit permissions and workgroup membership to users. It also allows differential access to system installations within the company or outside the company. The ProofPlus Client Interface (Command Layer) enforces permissions as requests from users are received. The system of permissions controls a view of the individual of the system by means of the control of the display of the user's screen and the components of the network ("portlets") to other actions of the system deployed when the user registers. For example, a user whose task is to manage documents will have a complete screen of all the objects in the system: publication files, active editions, tracking of issues, equipment and a fully articulated view of the revision status of the active editions. A contribution editor will see a more restricted view, allowing access only to those active editions of which he / she is a collaborator and to the related system installations. The system may include a request processor that manages a number of discrete user permissions such as, but not limited to: Create documents Write components Edit component properties Edit element usage rules Review tests Comment on tests Update (edit) documents Generate proofs Approve and withdraw approval of documents Publish documents Update tables of commercial objects Access, create and edit tables (content) Remove components from the library Access, create and edit footnotes Receive automatic notifications of published documents • Receive automatic notifications of new documents that have been created • Receive automatic notifications whenever tables have been loaded to a document • System management by the client • Management of the system by the server • Print production specifications • Memos of communication In one embodiment of the invention, the user interface operates over the Internet to connect users to a system server. The Command Layer examines the user's permissions and monitors the choices made by the user and returns the appropriate responses, both open to the user and hidden (as in file). As an example, the libraries, the file, and the programs used in the system are stored on an Internet server. In a system mode, users interact with the system by registering on a network site using their browsers as access portals. Critics can enter into a collaborative work procedure on the Internet. Because the interface and recovery tools are Internet-based, the system is always available and work can be done through time zones and from any device enabled to access the Internet.
Print Preparation In a system mode that results in printed publications, the system automates many steps that take the approved test to print-ready files. The approved test has changed its color model to CMYK, cutting lines and other print marks inserted, and all the imposition settings that make the files convenient for the complete color separations and plate making. In addition, the system can produce secure and compressed PDF files in a red-green-blue (RGB) color ready for the network, send notifications to users and managers, and communicate print and traffic notifications. The documents are then moved to the published file. Other output destinations can be added to the procedure to support different views of the final tests. Although they are made of reusable automated components, all publications have to be managed as if they were conventional documents. Once an edition has been published, it is stored in the file of the document as a file structured in series and as a virtual document, a map of its elements. The last case of other target formats, such as HTML or EDGAR II, is also placed in the file. While an edition is active, the file maintains all the evidence in the document to facilitate the marked revision and to act as a recovery module. The file is not part of the component library but a separate part of the system.
Conceptual view of the user regarding the system in operation Figures 27, 28 and 29 present a description of the publication procedure from the points of view of several users and this description can be summarized as follows: First, a user , which functions as the editing manager, creates an edition of a publication. An edition is a periodic repetition of a publication, whether the repetition is instigated by a predetermined program or by the regulatory / market requirements. The editions may incorporate new content and / or revisions of the previous edition. When a new edition is being prepared, it is said that this is an active edition. The active edition can be edited, which includes the addition of new components as guaranteed or desired. The user can now edit the active assembled edition, navigating through the hybrid tree screen and making changes to the edit panel as described above. The user who manages the edition can request proof of an active edition at any time. The user can request a test with marked revisions in addition to a clean version. The marked revision is dynamic in the sense that the new test can be compared with any other test or with the opening status of the document according to the user's request. Each time the user generates a test, he has the option of receiving a test with marked revisions and choosing the test for comparison. Therefore, the variation in the levels of cumulative changes can be documented. Subsequently, the user who manages the edition distributes the tests for review and comments. The manager can choose from multiple distribution lists and also add individual receivers. Reviewers, editors and managers can access the test over the Internet or other network connection. Changes and comments regarding the components of the document are labeled from test to test. While a test is being reviewed, a user may have a problem with the test which requires examination; by making an electronic comment, the user enters the comment in the problem tracking system. The user can also consult an audit log that tracks all changes to the content of the component with respect to who, when and what context, and why the revisions were made. Changes are shown as screens with checked revisions that include all statistical information for each and every revision. The audit record can also be useful for financial institutions that have to maintain detailed records due to regulatory requirements established by the US government such as the Sarbanes-Oxley Act of 2002. Users with appropriate permits can edit, retest, and review the tests as necessary. A privileged user can pass a test as a final version of the edition and later, "publish" the approved test. When an approved test is published, as shown in Figure 19, approval is granted for distribution to the target group of recipients in the particular formats established for the deployment time. A published document represents the final status of the current edition that is archived. Although particular deployments can create tax printing origins, they can deliver special electronic formats to certain recipients, and can place publications on a network or any other network site, these actions are subsequent to the publishing action in the system and do not affect the structure of underlying storage of the published document. After a test is approved for publication, a reviewer or editor may decide that a component or multiple components may need editing. In such cases, approval for publication may be revoked. At the time of revocation, the collaborators and the editing manager can choose to assemble and edit as usual or they can request a mode of operation called restricted edition. In the restricted edition, the user observes a list of shared components within the active edition that has been revised since the current edition was approved for publication. The user can choose whether or not to apply these revisions to the active edition in restricted mode. Any of the editions that caused the revocation of the approved status can be applied to the current document only (and expire with the edition), applied to all the qualified documents immediately, or applied to all future qualified active editions. Although preferred embodiments of the present invention and modifications thereof have been described in detail herein, it will be understood that the present invention is not limited to those precise embodiments and modifications, and that other modifications may be made by those skilled in the art. and variations without departing from the spirit and scope of the invention, as defined in the appended claims.

Claims (19)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS
1. - An automated document publishing system comprising: a user interface for managing a document; a memory having data stored therein, said data includes at least one of a content library, structural rules, specific deployment data, or specific commercial deployment procedures; a processor for automatically assembling an active edition of the document based on said data stored in said memory; wherein a proof of said document is generated from said active edition; and where said document is published when said proof is approved.
2. The system according to claim 1, characterized in that the content in said content library is accommodated as a plurality of components, said plurality of components is enabled to be shared by a number of documents.
3. The system according to claim 1, wherein said document is a structured document comprising a number of elements, each element provides structural information or relating to a component stored in said content library.
4. The system according to claim 1, further comprising a generator of issues to generate a number of issues associated with said test before the approval of said test.
5. - A method for automatically publishing a document comprising the steps of: assembling an active edition of said document at least from one of a content library, structural rules, specific deployment data, or specific commercial procedures for deployment; edit that active edition using a user interface; generate a test from said active edition; review said test; and publish that proof.
6. - The method according to claim 5, characterized in that said additional revision step comprises editing said active edition used to generate said test to generate a new test for review.
7. - The method according to claim 5, further comprising the step of generating a number of issues associated with said test, wherein a user has to deal with said number of issues before said test is published.
8. A content controlled version library comprising a number of components that have content associated therewith, wherein each of said number of components has a number of versions associated therewith.
9. The controlled content content library according to claim 8, characterized in that said number of versions are translations of foreign languages of the components with which said number of versions is associated.
10. The controlled version content library according to claim 8, characterized in that said number of versions are customized for specific locations.
11. The controlled version content library according to claim 8, characterized in that said components are shared by a plurality of documents.
12. The controlled content content library according to claim 8, characterized in that said components are enabled to be edited by a user and said user, through the use of a user interface, can use the edited components for said user. document, all future documents, all archived documents, or all documents.
13. The controlled version content library according to claim 12, characterized in that there is an audit record of all the editions made for said components. 14.- A structure bar that describes a conceptual and organizational structure of a document; said structure bar comprises: a container representing a section of said document, a component associated with an element in said document in said container; a number of handles, each handle associated with a single container or component, said handle being used to manipulate said container component. 15. The structure bar according to claim 14, further comprising a hybrid tree diagram where the user can navigate in said document that is being edited. 16. The structure bar according to claim 14, characterized in that said structure bar executes the rules of the structure of the document and the marking syntax. 17. A virtual structured document comprising: structural elements for constructing a structure for said virtual structured document; and content elements to define the locations in said virtual structured document to place indicators for the components residing in a content library; wherein said virtual structured document is assembled based on at least one of structural rules, specific deployment data, or specific commercial deployment procedures. 18. The virtual structured document according to claim 17, further comprising required components, wherein said virtual structured document can not be approved for publication unless said required elements are in said virtual structured document. 19. The virtual structured document according to claim 17, characterized in that the system identifies the candidate components for use in said virtual structured document based on at least one of context rules, specific deployment data, specific commercial procedures of deployment or component properties. SUMMARY OF THE INVENTION The present invention automates the publication of financial, legal and governmental documents and any other publications that are structured and that require compliance with corporate or external standards and that may share content elements; it provides users with control in a familiar, always informed environment: the Internet; Due to its virtual document architecture and the ability to operate over the Internet and Intranet (internal networks), the system facilitates collaborative work and tracks responsibility; the key concept behind automated publishing is to control programming and costs through better content management; the present invention handles the content of documents as small reusable components, up to a paragraph level and frame cell; the interface helps users assemble documents from these controlled version components with automated support; the system applies the context and filters the criteria stored with each component to locate and apply the content fragments to a current document; the system of the present invention can apply structural rules and content regiments to guarantee compliance with the regulatory requirements and the commercial rules of the company; a virtual document in operation within the system always incorporates the current version of all the elements that constitute it.
MXPA/A/2006/000161A 2003-07-08 2006-01-05 An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture MXPA06000161A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US60/485,472 2003-07-08

Publications (1)

Publication Number Publication Date
MXPA06000161A true MXPA06000161A (en) 2007-04-20

Family

ID=

Similar Documents

Publication Publication Date Title
CA2528583C (en) An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture
US8606607B2 (en) Translation processing using a translation memory
US20180217967A1 (en) Systems, Methods, and Media for Controlling the Review of a Document
Madhusudhan et al. Integrated library management systems: Comparative analysis of Koha, Libsys, NewGenLib, and Virtua
Spiro Archival management software
Ballard et al. IBM infosphere streams: accelerating deployments with analytic accelerators
MXPA06000161A (en) An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture
Rahal Tools for transparency in central government spending
Klemt-Albert et al. Utilising the potential of standardised bim models by a fundamental transformation of collaboration processes
WO2008145981A2 (en) Information management systems
Jennings Microsoft Access 2010 in depth
Crystal-Ornelas et al. A Guide to Using GitHub for Developing and Versioning Data Standards and Reporting
US10607239B2 (en) Enterprise evaluation using structured data
Viana et al. Assertive Wiki: An Experience Report In The Industry on the Redesign of Software Requirements Documentation
Theodórsdóttir et al. Evaluation of Text–Based Requirements Engineering Tools
Lejon Information Management in Computer-Aided Product Development
Singh Integrated library management systems: Comparative analysis of Koha, Libsys, NewGenLib, and Virtua
Henderson The Hand Press Book File in RLIN: the development of a European unified database
Janiesch et al. Document Variant Management-Facilitating Enterprise System Definition, Configuration, and Interoperability
Herrero Columbus: a solution using metadata for integrating document management, project hosting and document control in the construction industry
Laplante et al. KM AS A FRAMEWORK FOR MANAGING KNOWLEDGE ASSETS
PP et al. Project Number IST-2006-033789 Project Title Planets Sub-Project Title Preservation Planning Work Package Title Preservation Policy and Strategy Models Work Package Identifier PP2
Asprey et al. Functional Requirements-Engineering and Technical Drawings
Smith Development and deployment of document management technology into Rover: executive summary
Labrenz et al. Ingo Glaser, Tri Huynh, Oleksandra Klymenko