JP2009519507A - Document processing system and method - Google Patents

Abstract

The present invention includes a document layer including an application layer that transmits a standard command for operating a document that conforms to a general-purpose document model, and a document-based system that receives the standard command and operates document data based on the standard command. A processing system is disclosed. The present invention also discloses a document processing method. According to the present invention, the application layer and the data processing layer are separated. In this way, the application is not directly related to a specific document format, the document is not bound to a specific application, the same document can be used for different applications, and the same application can operate different documents. Thus, interoperability of documents is realized.
[Selection] Figure 1

Description

  The present invention relates to a document processing system and method.

  Information is roughly divided into structured data and unstructured data. Among them, the share of unstructured data, mainly text documents and streaming media, exceeds 70% due to data statistics. The structure of the structured data is a two-dimensional table structure and is relatively simple. Structured data processing technology is mainly processing using a database system. It has developed since the 70s and 80s of the 20th century and reached its peak in the 90s, and its research and development and application have already matured. . Since unstructured data does not have a fixed data structure, the processing for unstructured data is very complicated.

  At present, applications for processing various unstructured documents are already in widespread use, and various document formats coexist. For example, there are currently Microsoft (registered trademark) word and WPS, Office of Naganaka Technology Co., Ltd., and Red Office. Typically, a single content management application may process over 200,300 document formats, and these formats are constantly being updated, creating significant difficulties in developing such applications. . Increasingly, document versatility, digital content extraction, and format compatibility are focused on solving the following problems:

1) The document cannot be used for general purposes.
Basically, different users can only exchange documents processed by the same application, and cannot exchange documents processed by different applications, leading to information closure.

2) The access interface is not uniform and the price of data compatibility is too high.
The document formats are not compatible with each other between different document processing applications. During processing, the partner format is analyzed using the partner component (assuming that the partner provides a corresponding interface) Or you have to put your own research and development power and analyze from the beginning to the end.

3) Information security is poor.
Currently, there is a single authority control means for text documents, mainly including data encryption and password authentication. Every year, incidents in which a company loses huge losses due to information leaks occur.

4) The process is for only a single document and there are few multi-document management means.
There are a large number of documents on each person's computer, but effective organization management is scarce among a plurality of documents, and it is difficult to share resources. For example, font / typeface file and full text data search.

5) Page hierarchies are inadequate.
Currently, applications such as Adobe® Photoshop and Microsoft Word have some concept of layers, but the layers are still simple in function, relatively easy to manage and meet application needs. I can't meet.

6) There are not many search means.
As the amount of information increases, searching with any keyword results in an enormous amount of search results. Although the problem of recall is almost solved by full-text search technology, the precision is quickly becoming the most important issue. In the prior art, all information is not fully used for solving the problem of the precision ratio. For example, the typeface and character size of each character can be used for determining the importance of this character, but have been ignored during the search.

  Currently, all major companies are striving to develop their own document formats into market standards, and each standardization organization is also making efforts to establish general-purpose document format standards. However, the following problems are unavoidable as long as the document format is used as a standard regardless of the proprietary document format (for example, doc) or the open document format (for example, PDF).

a) Duplicate development and inconsistent effects The need for different applications that use the same document format standard to interpret and generate documents in this format by themselves leads to a large amount of duplicate development. Also, the interpretation programs for each application are different, for example, some are well maintained, some are relatively simple, some support the new version, and some only support the old version. For this reason, the same document is displayed with different page layouts by different applications, and as a result, an interpretation error may occur and the document cannot be opened.

b) Obstacle to innovation Although the software industry is an industry that is constantly innovating, it is necessary to add descriptive information for this function each time a new function is added, and the addition of a new format is a modification of the standard. Because you can only wait until time, fixing the storage format hinders competition for innovation.

c) Influence on search performance To improve search performance for a large amount of information, it is necessary to add a large amount of search information, but it is difficult to add search information for a fixed storage format.

d) Impact on portability and scalability Under different system environments, there may be different storage requirements due to different application needs. For example, when storing in a hard disk, it is necessary to consider how to reduce the number of seeks of the disk head so as to improve performance. On the other hand, in the embedded application, since the data corresponds to the data stored in the memory, the above problem does not occur. For example, the same manufacturer's database application may use different storage formats on different platforms. Therefore, setting document storage standards affects the portability and expandability of the system.

  The most open and most compatible document in the prior art is Adobe Acrobat's PDF. However, even though PDF has already become a de facto standard for global document distribution and exchange, it is not possible to exchange PDF documents between different applications, that is, interoperability of PDF documents cannot be realized. . Regardless of Acrobat or Office, only a single document can be processed, a management function for multi-documents is scarce, and a document base operation function is not provided.

  The prior art also has many defects in document information security. All documents with the widest range of applications such as Word and PDF use data encryption or password authentication to perform data security control, but do not provide a systematic identity authentication mechanism, and authority control In this range, it is not possible to refine to an arbitrary area in the document, and encryption and signature cannot be set for arbitrary logic data. Conventional content management systems can provide a relatively good identity authentication mechanism, but because they are separated from the document processing system, they can not only achieve document-level management granularity, but also provide security for documents while they are in use. It is difficult to implement necessary security management because control cannot be performed. As can be seen from the above, since the conventional security mechanism and document processing are each realized by a single module, security flaws are likely to occur.

  The present invention provides a document processing system and method capable of realizing document interoperability, multi-document management, better document security, and better query retrieval.

According to one aspect of the present invention, a document processing system comprising:
An application layer that sends standard directives for manipulating documents that conform to the generic document model;
A document-based system that receives the standard command and manipulates document data based on the standard command.

According to another aspect of the present invention, a document processing system comprising:
An application layer having at least one application;
An interface layer for transmitting a standard command for operating a document conforming to the general-purpose document model from the application layer;
A document-based system for manipulating document data based on the standard command.

A document processing method,
A process in which the application layer sends standard commands for manipulating documents that conform to the generic document model;
A document-based system including manipulating document data based on the standard command.

The present invention also provides an application. The application
It includes an interface unit that sends standard commands for manipulating documents that conform to the generic document model.

The present invention also provides a document-based system. The document-based system is
An interface unit that receives standard commands for manipulating documents that conform to the general-purpose document model;
And a processing unit for manipulating document data based on the standard command.

The present invention also provides an interface layer. The interface layer
An upper interface unit that sends standard commands for manipulating documents that conform to the generic document model;
And a lower interface unit that receives the standard command.

  According to the present invention, the current state of realizing from the user interface to document storage by one application is changed. In the present invention, document processing is divided into an application layer and a document-based system layer, and an interface standard that defines exchanges between both layers is defined. An interface layer that conforms to this interface standard may be further constructed. The document-based system is a general-purpose technology platform having various document manipulation functions. When an application tries to manipulate a document, a corresponding command is transmitted to the document-based system through the interface layer. The corresponding operation is executed based on Thus, as long as each application and each document-based system follow similar standards, different applications can manipulate the same document via the same document-based system, ie, document interoperability. Similarly, the same application can operate different documents via different document-based systems without having to develop each according to various document formats.

  The present invention also includes a general-purpose document model, and this model can be adapted to a document that needs processing of each application. Since the interface standard is determined based on the document model, it is possible to realize that different applications can operate the document through the interface layer. Since this general-purpose document model can be applied to various document formats, the same application can operate documents of different formats via the interface layer.

  The interface standard defines various commands for manipulating a document based on the general-purpose document model, and a command transmission method from an application to a document base system. The document-based system has a function for realizing these commands from the application.

  The general-purpose document model also includes hierarchies such as document sets, document bases, and document warehouses composed of multiple documents. The interface standard also includes commands such as multi-document organization management, query retrieval, and security control. Is included.

  In addition, the general model includes pages composed of layers having an upper and lower order, and the interface standard also includes various operation commands for the layers and storage and retrieval of source files corresponding to a certain layer of the document. .

  The document base system has a document information security management control function such as fine-grained authority management based on roles, and related operation commands are defined in the interface standard.

  According to the present invention, the application layer and the data processing layer are separated. In this way, the application is not directly related to a specific document format, the document is not bound to a specific application, the same document can be generalized between different applications, and the same application can operate different documents. Document interoperability. The entire document processing system is not limited to single document processing, and also has a multi-document processing function. Dividing a page into multiple layers can realize different management and control for different layers, and operations on the same page by different applications (may be designed to manage and maintain different layers by different applications) It becomes more convenient. This is convenient for editing with the source file method, and is also a method for saving history. By incorporating information security into the core layer of document processing, security flaws can be eliminated, and security mechanisms and document operations are closely integrated, not two separable modules, and the security management technology deployment space More and more, related code can be hidden more deeply, illegal attacks can be effectively prevented, security reliability can be improved, more privilege classification and fine-grained security management like smaller management units Means can be provided.

  Hereinafter, the present invention will be described in more detail with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are used only to interpret the present invention and are not intended to limit the present invention.

  As shown in FIG. 1, the document processing system according to the present invention mainly includes an application, an interface layer, a document base system, and a storage device.

  Applications here include any conventional document processing and content management application. These applications are located in the application layer of the document processing system and manipulate documents by sending commands that conform to interface standards. All of the above operations are performed on a document conforming to the general-purpose document model, and are not related to a specific storage format.

  The interface layer here conforms to the interface standard that prescribes the exchange between the application layer and the document-based system. The application layer transmits a standard command to the document base system via the interface layer, and the document base system returns an execution result to the application layer via the interface layer. As can be seen from the above, all applications can send standard commands via the interface layer and manipulate documents that conform to the general-purpose document model, so different applications can manipulate the same document via the same document-based system. Can also handle documents of different formats via different document-based systems.

  Preferably, the interface layer may include an upper interface unit and a lower interface unit. The application sends standard commands to the lower interface unit via the upper interface unit, the document-based system receives standard commands via the lower interface unit, and the lower interface unit also executes the document-based system via the upper interface unit. Send the result back to the application. In implementation, the upper interface unit may be located in the application layer and the lower interface unit may be located in the document-based system.

  The document base system here is a core layer of the document processing system, and executes a specific document processing operation based on a standard command transmitted from the application through the interface layer.

  The storage device here is the storage layer of the document processing system, usually including a hard disk or memory, and may include a compact disk, flash memory, floppy disk, tape, or remote storage, i.e., even with data storage capability. That's fine. Although a plurality of documents are stored in the storage device, it is not necessary for the application to pay attention to a specific document storage method.

  As can be seen from the above, according to the present invention, the application layer and the data processing layer are surely separated, the document is not bound to a specific application, and the application is not directly related to a specific document format. The same document that conforms to the general-purpose document model can be edited, and the document has excellent interoperability between different applications.

  The present invention also discloses an application. The application includes an interface unit that transmits standard commands for manipulating documents that conform to the general document model.

  The present invention also discloses a document-based system. The document-based system includes an interface unit that receives a standard command, and a processing unit that operates a document that conforms to a general-purpose document model based on the standard command.

The present invention also discloses an interface layer. The interface layer is
An upper interface unit that sends standard commands for manipulating documents that conform to the generic document model;
And a lower interface unit that receives the standard command.

  Further, the upper interface unit may generate a standard command based on the command from the application layer, and the lower interface unit may determine whether the received command conforms to the standard and analyze the command conforming to the standard. .

  Hereinafter, specific embodiments of a document processing system according to the present invention will be described.

[General document model]
The general-purpose document model may be defined with reference to paper characteristics. This is because it is the standard method that has been used so far to use paper as a document information recording means, and if all the functions of paper are available, it can satisfy actual application needs such as work and life. is there.

  This general document model can describe all visible content on a page if one page in the document is considered a sheet of paper and anything that can be written on the paper is recorded. Since a conventional page description language (for example, PostScript) can describe all information that can be printed on paper, a detailed description thereof will be omitted. In general, the visible content on the page may ultimately be divided into three types: text, graphics, and images.

  When a document is related to a specific typeface or special character, it is necessary to incorporate a corresponding font into the document to ensure the same effect on each computer. Font resources should be shared to improve storage efficiency. In this way, even if the same character is used in a plurality of places, only one font needs to be incorporated. Images may also appear in multiple locations, for example, a common background image on each page or a company logo that always appears. Even in this case, it is better to share these images.

  Of course, more advanced information processing tools need to not only simulate paper properties, but also add enhanced digital properties such as metadata, navigation, threads, and thumbnail images. The metadata includes data for describing the data. For example, book metadata includes author, publisher, publication date, ISBN number, and the like. Since metadata is a common term in the industry, description thereof is omitted here. Navigation includes information such as the table of contents of a book, which is also a common term in the industry. Since the thread information describes the document's location area and reading order, what should be displayed on the next screen after the reader has read one screen can be automatically determined based on that information. Depending on the thread information, automatic page breaks and page breaks can be realized without the reader having to manually specify the position. The thumbnail image includes a reduced view of each page generated in advance. Readers can specify which pages to read by examining thumbnail images.

FIG. 2 is a general-purpose document model according to a preferred embodiment of the present invention. As shown in FIG. 2, the general-purpose document model includes a plurality of hierarchies such as a document warehouse, a document base, a document set, a document, a page, a layer, an object group, and a layout object.
Here, the document warehouse consists of one or more document bases. Compared with the relationship between lower levels of the document base, the relationship between the document bases is relatively loose, and the document bases can be easily combined and disassembled without correcting the data of the document base itself. Since there is often no unified index (especially a full-text index) between these multiple document bases, there is usually no unified index that can be used for many search operations on the document warehouse. The base index needs to be scanned. Each document base consists of one or more document sets. Each document set consists of one or more documents, and may include any number of sub-document sets. The document mentioned here includes a current ordinary document file (for example, a DOC document). In the general-purpose document model, it may be specified that one document belongs to only one document set, but one document may be allowed to belong to a plurality of document sets. The document base is not a simple combination of a plurality of documents, but a close organization of a plurality of documents. In particular, creating various unified search indexes for document content provides greater convenience.

  Each document is composed of one page or a plurality of pages having a certain order (for example, front and back order). The plate surface of each page may be different, and the plate surface is not necessarily rectangular, and may be an arbitrary shape, and can be represented by one or a plurality of closed curves.

  Each page is composed of one layer or a plurality of layers having a certain order (for example, up and down order). Each layer has a relationship like an overlapping glass plate. A layer consists of an arbitrary number of layout objects and object groups. Layout objects include status (eg, typeface, character size, color, ROP, etc.), text (including symbols), figures (eg, straight lines, curves, closed areas filled with specified colors, gradation colors, etc.), images (Eg, TIF, JPEG, BMP, JBIG, etc.), semantic information (eg, title start, title end, line feed, etc.), source file, script, plug-in, embedded object, bookmark, hyperlink, streaming media, 2 Including value data stream. One or more layout objects may be configured into one object group. Any number of sub-object groups may be included in the object group.

  The document base, document set, document, page, layer may further include metadata (eg, name, last modification time, etc., the type can be set according to application needs) and / or history. The document may further include navigation information, thread information, and thumbnail images. Thumbnail images may be placed at the page or layer level. The document base, document set, document, page, layer, object group may further include a digital signature. Semantic information should follow the layout information. As a result, data redundancy can be avoided, and establishment of a correspondence relationship with the layout becomes relatively easy. The document base and the document may include shared resources such as fonts and images.

  In this general-purpose document model, one or a plurality of roles may be defined and a certain authority may be allocated to each role. The authority is distributed as a unit based on document base, document set, document, page, layer, object group, and metadata, and for each role, readability / writeability / copyability / printability are defined. .

  This general-purpose document model goes beyond the conventional method in which a single document corresponds to a single file. The document base includes a plurality of document sets, and the document set includes a plurality of documents. By adopting fine-grained access and security control for the document contents in the document base, unlike the conventional document management system that can only access the file name level, up to a certain character or rectangle in the document base Specifically accessible.

  3 to 9 are diagrams showing the configuration of each object related to the general-purpose document model according to the preferred embodiment of the present invention. Each object has a tree structure, and is expanded and subdivided for each layer.

  A document warehouse object consists of one or more document base objects (not shown).

  As shown in FIG. 3, the document base object includes one or a plurality of document set objects, an arbitrary number of document base auxiliary objects, and an arbitrary number of document base shared objects.

  As shown in FIG. 4, the document-based auxiliary objects include metadata objects, role objects, authority objects, plug-in objects, index information objects, script objects, digital signature objects, history objects, and the like. The document base shared object includes an object that can be shared by different documents in the document base, such as a font object and an image object.

  As shown in FIG. 5, each document set object includes one or more document objects, an arbitrary number of document set objects, and an arbitrary number of document set auxiliary objects. The document set auxiliary object includes a metadata object, a digital signature object, and a history object. When a plurality of document set objects are included in the document set object, it is similar to a format in which a plurality of folders are included in one folder in Explorer.

  As shown in FIG. 6, each document object includes one or a plurality of page objects, an arbitrary number of document auxiliary objects, and an arbitrary number of document shared objects. The document auxiliary objects include a metadata object, a font object, a navigation information object, a thread information object, a thumbnail image object, a digital signature object, a history object, and the like. The document shared object includes an object that can be commonly used for different pages in the document, such as an image object or a seal object.

  As shown in FIG. 7, each page object includes one or a plurality of layer objects and an arbitrary number of page auxiliary objects. The page auxiliary object includes a metadata object, a digital signature object, and a history object.

  As shown in FIG. 8, each layer object includes one or more layout objects, an arbitrary number of object groups, and an arbitrary number of layer auxiliary objects. Layer auxiliary objects include metadata objects, digital signature objects, and history objects. The object group includes any number of layout objects, any number of object groups, and selectable digital signature objects. When an object group includes a plurality of object groups, it is similar to a format in which a plurality of folders are included in one folder in Explorer.

  As shown in FIG. 9, layout objects include status objects, text objects, line objects, curve objects, arc objects, path objects, gradation color objects, image objects, streaming media objects, metadata objects, comment objects, and semantic information. Objects, source file objects, script objects, plug-in objects, binary data stream objects, bookmark objects, and hyperlink objects are included.

  Here, the status object includes any number of character set objects, typeface objects, character size objects, character color objects, raster operation objects, background color objects, line color objects, fill color objects, line type objects, A line width object, a seam object, a brush object, a shadow object, a shadow color object, a rotation object, a bag character object, a border character object, a transparent object, and a rendering mode object are included.

  In a specific implementation process, the general-purpose document model may be further strengthened or simplified. When the document set object is omitted from the simplified model, the document base object directly includes the document object, and when the layer object is omitted from the simplified model, the page object directly includes the layout object.

  It can be seen that the most simplified general-purpose document model includes only document objects, page objects, and layout objects. Here, the layout object includes only a text object, a straight line object, and an image object. Various intermediate models between the full model and the most simplified model are variations of this preferred embodiment.

[General document security model]
In order to meet the needs for document security by various applications, the document security function of the conventional application is not so strong, or the general purpose so as to solve the security flaw caused by the disconnection between the security management mechanism and the document processing module A document security model needs to be defined. According to a preferred embodiment of the present invention, the universal document security model includes:

1. Roll object Defines some roles in the document base. Usually, a roll object is a sub-object of a document base object. If there is no document base object in the corresponding generic document model, the role is defined in the document, i.e. the roll object is a sub-object of the document object. In this case, all document bases referred to in this general document security model should be replaced by documents.

2. Specification of access authority of role Access authority to an arbitrary object (for example, document base, document set, document, page, layer, object group, layout object, etc.) by an arbitrary role can be specified. When an access authority to an object is specified for a certain role, this authority is applied to all sub-objects of the object.
Here, the access authority realized in the document-based system includes read permission / rejection permission / rewrite permission / re-assignment (that is, permission of a part or all of the other roles), authority release (that is, other roles). And any combination of the above is included. You can also define other permissions that require application cooperation to be realized, such as printing disabled.

3. Object signing with role identity A role can sign any object. A signature range for an object includes a sub-object of the object and an object cited by the object.

4). Role Creation The execution result of the role object creation command is to return a key for logging in with the role status from the application to the application. This key is usually a private key of the PKI and is stored by the application. This key may be a login password. Preferably, any application has the authority to create a new role without any authority. It is possible to give a certain authority to a new role using a role with re-grant authority.

5. Role Identity Login When an application logs in with a role identity, a “challenge / response” mechanism is usually employed. That is, the document-based system encrypts the random data block using the public key of the stored role, sends it to the application, and the application decrypts the encrypted data before returning it to the document-based system. If the decryption is correct, it means that the application has a private key corresponding to this role. The “challenge / response” mechanism can also be realized in the following manner. That is, the document-based system sends a random data block to the application, the application encrypts it with a private key and then sends it back to the document-based system. The document-based system uses the public key of the stored role. Thus, if the decrypted one is decrypted and the decryption is correct, it means that the application surely has a private key corresponding to this role. As a precaution, this authentication process can be repeated many times. By using the “challenge / response” mechanism, the security of the private key can be better protected. If the role key is a login password, the user must enter the correct login password. An application may log in with a plurality of roles at the same time. At this time, the authority of the application is a union of the authorities of the plurality of roles.

6). Default role A special default role can be created. If a default role exists, the document base can be operated with the identity of the default role without logging in as any role. Preferably, a default role having all privileges is automatically created at the initial creation of the document base.

  In a specific implementation process, the general-purpose document security model may be further strengthened or simplified. Any simplified model for the general document security model is a variation of this embodiment.

[Specific implementation of interface layer]
The unified interface standard of the interface layer may be defined based on a general-purpose document model, a general-purpose document security model, and a regular document operation, and is used for transmitting an operation command for each object in the general-purpose document model. The operation command for each object in the general-purpose document model conforms to the interface standard, and various applications can transmit the standard command through the interface layer.

  The following introduces the implementation method of the interface standard. In order to realize the interface standard, the upper interface unit follows the predefined standard format, for example, “<UOML_INSERT (OBJ = PAGE, PARENT = 123.456.789, POS = 3) />”. And the instruction sequence may be transmitted to the lower interface unit, and the execution result or other feedback information for the instruction may be received from the document-based system via the lower interface unit. Or, in order to realize the interface standard, the lower interface unit provides some interface functions with standard names and parameters, such as “BOOT UOI_InsertPage (UOI_Doc * pDoc, int nPage)”. And the call operation itself may mean that the upper interface unit sends a standard command. Alternatively, the above methods may be combined to implement an interface standard.

  When the interface standard is realized by the “operation operation + operation object” method, it is convenient for studying and understanding the interface standard, and also for maintaining the stability of the interface standard. For example, when 10 types of operations are performed on 20 types of different objects, 20 × 10 = 200 types of commands may be defined, or 20 types of objects and 10 types of operations may be defined. However, in the latter method, it is clear that the memory burden is greatly reduced, and when the interface standard is extended in the future, it is easy to add objects or actions. The operation object is an object included in the general-purpose document model.

For example, the following seven types of operation are defined.
Open: Create or open a document base.
Close: Closes the session handle or document base.
Get: Get object list, related attributes and data of object.
Setting: Set / modify object data.
Insert: Inserts the specified object or data.
Delete: Delete a sub-object with an object.
Search query: Searches the document for content that meets the conditions according to the defined conditions. These conditions may be accurate information or incorrect information. That is, fuzzy search is supported.

  Document base, document set, document, page, layer, object group, text, image, figure, path (a group consisting of figures connected in order, and the figure here may be an open figure or a closed figure) Define objects such as source files, scripts, plug-ins, audio, video, roles, etc.

  The objects include status objects such as background color, line color, fill color, line type, line width, ROP, brush, shadow, shadow color, character height, character width, rotation, transparency, and rendering mode.

  When the interface standard is realized by the method of “operation operation + operation object”, it should not be automatically recognized that all combinations of each object and each operation can constitute an actual meaningful operation command. It can be understood that the combination of is meaningless.

  The interface standard may be defined by a function method other than “operation operation + operation object”. For example, if one interface function is defined for each operation of each object, various operation commands are transmitted to the document base system by calling the interface function of the lower interface unit from the upper interface unit.

  Each object may be encapsulated to form a class such as a document base class, and operations that can be performed on the object may be defined as methods of the class.

  In particular, when a page bitmap acquisition command is defined in the interface standard, it plays an important role in ensuring layout consistency and document interoperability.

  The page bitmap acquisition command allows the application to interpret this layout object by itself without displaying and processing the page bitmap in the specified bitmap format of the specified page, that is, the display effect of this page expressed in the bitmap format. Can be obtained directly. In other words, an application can directly acquire an accurate page bitmap for displaying and printing a document, but it can read each layout object of each layer of the page by itself, interpret the meaning of the object, and reflect it in the layout. Is no longer necessary. If an application interprets an object on its own, the interpretation of one application must be relatively complete and accurate, and the interpretation by one application must be incomplete or inaccurate. Display and print with different effects, affecting the user experience in terms of document interoperability. The key point of layout consistency maintenance has been shifted from the application to the document-based system by the method of generating the page bitmap uniformly in the document-based system. Thereby, when the same document is opened by different applications, the same layout effect can be obtained. As one of the causes, it is possible for a document-based system, which is a unified basic technology platform, to interpret and process each layout object completely and accurately, but not for an application. As another cause, different applications can be used in combination with the same document base system so as to further ensure the consistency of the display and printing effects. In short, consistency between applications is not so much possible, consistency between document-based systems is possible, and consistency within the same document-based system has no further problems. Therefore, in order to maintain the layout consistency of the same document between different applications, it is necessary to transfer the related responsibilities from the application to the document-based system. One simple method is to generate page bitmaps uniformly in a document-based system.

  Furthermore, one page area may be specified in the page bitmap acquisition command so that only one area of the page is displayed. For example, when the page is larger than the screen, it is not necessary to display the entire page, and when scrolling the page, it is only necessary to redraw the scrolled area. If the directive allows you to specify the acquisition of a page bitmap consisting of a specific layer, and in particular to specify the acquisition of a page bitmap consisting of a specific layer and all lower layers of the layer, the history It can be expressed well, i.e. the layout effect can be seen before adding a recent layer or earlier. As required, it may be specifically specified which layer is used for generating the bitmap and which layer is not used.

The search inquiry command can provide more abundant search means besides normal keyword search. With normal search technology, search is separate from document processing, and the search program can only extract plain text information from the document and cannot obtain more information, so it cannot search based only on text information. . In the present invention, by incorporating the search inquiry function into the core layer of document processing, that is, the document base system, a stronger search means can be provided by fully utilizing the information contained in the document. For example,
1. A search based on typeface information, for example, a search for “calligraphy” in black font, a search for “Sursen” in Times New Roman style.
2. Search based on character size information, for example, search for “Book Student” of No. 3, search for “Sursen” of 20 points or more, and “document base” search for long characters (ie, the character height exceeds the character width).
3. Search based on color, for example, search for red “book student”, search for blue “Sursen”.
4). Search based on layout position, for example, search for “book student” in the upper half of the page, search for “Sursen” in the footer.
5. Search based on special effects of character modification, for example, search for “student” in italic, search for “Sursen” rotated 30 to 90 degrees clockwise, search for “SEP” in bag, “Document-based” search.
6). By using a similar concept, it is possible to provide other types of search, such as a search for “book student” with black and white reversal (white on black), a search for “Sursen” superimposed on an image, and the like.
7). It is possible to search for a combination of a plurality of layout objects, for example, those in which the distance between “book student” and “Sursen” does not exceed 5 cm.
8). Any combination of the above search conditions.

  The following is an embodiment for realizing an interface standard by the method of “operation operation + operation object”. In this embodiment, the interface is referred to as Unstructured Operation Markup Language (UOML) and is a series of instructions written in an extensible markup language (XML). The upper interface unit generates a character string that conforms to the UOML format, and transmits this character string to the lower interface unit, thereby transmitting a corresponding operation command to the document-based system. After the document-based system executes these instructions, the lower interface unit generates a character string that conforms to the UOML format for the execution result, and returns it to the upper interface unit, thereby causing the application to execute the operation. To inform.

  All execution results are represented by UOML_RET. UOML_RET is defined as follows.

Attribute SUCCESS: Indicates that the operation is successful when the value is true, and the operation is unsuccessful otherwise.
Sub-element ERR_INFO: Selectable, appears only when operation fails, and describes corresponding error information.
Other sub-elements: determined by specific instructions and may refer to the description for each instruction.

  UOML operations include the following.

1 UOML_OPEN (create or open a document base)
1.1 Attributes 1.1.1 Create: If true, create, otherwise open an existing document base.
1.2 Sub-element 1.2.1 Path: Document-based path. It may be a disk file name, URL, memory pointer, network path, document-based logic name, or other representation scheme that can specify a document base. The document base can be specified in a different manner if the above-mentioned various cases are classified by character strings having different characteristics, that is, the command format is not changed and only different characteristics are set for the character string. For example, the disk file name starts with the device name (for example, drive letter) and “:” (for example, “C:”, “D:”), and immediately after “:” is “//” or other “ :"is not. The URL starts with the protocol name and “: //” (for example, “http: //”). The memory pointer is represented by “MEM ::” at the head and the next is a pointer character string representation method, for example, “MEM :: 1234: 5678”. The network path starts with “\\”, and the next is the server name and server path, for example “\\ server \ abc \ def.sep”. The document-based logic name may start with “*”, for example “* MyDocBase1”. When the lower interface unit analyzes, if the first character is “*”, the character string indicates a document-based logic name, and if the first two characters are “\\”, the character string indicates a network path. If the first five characters are “MEM ::”, the character string represents a memory pointer. Otherwise, the first “:” in the character string is searched for, and the character “:” is followed by “ // "indicates a URL, otherwise it indicates a file on the local device. A special URL protocol may be set to distinguish when opening the document base of the server. For example, “Docbase: / myserver / mydoc2” is used to instruct to open the document base mydoc2 managed by the server system of the document base system in the server myserver. In short, the document base can be specified in different ways as long as different characteristics can be set in the character string. According to the above description, various different character string features may be defined. This method can be applied not only to the specification of a document base path, but also to other cases, in particular, an application case for specifying a specific resource position. Often you want to specify related resources in a new way, but you can't or do not want to change an existing protocol or function. At this time, it can be specified by a method of setting different characteristics in the character string. Such a method is optimally versatile, as it supports strings with any protocol or function, as long as it supports a disk file name or URL.
1.3 Return Value In case of success, a sub-element “handle” for recording the handle is added to UOML_RET.

2 UOML_CLOSE (close)
2.1 Attributes: None.
2.2 Sub-element 2.2.1 handle: An object handle which is a character string and is a reference pointer to an object.
2.2.2 db_handle: a document base handle that is a character string and is a citation pointer to the document base.
2.3 Return value: None.

3 UOML_GET (acquisition)
3.1 Attribute 3.1.1 usage: One of “GetHandle” (specified object handle acquisition), “GetObj” (specified object data acquisition), and “GetPageBmp” (page bitmap acquisition).
3.2 Sub-element 3.2.1 parent: A parent object handle, which is used when the usage attribute is “GetHandle”.
3.2.2 pos: Position order, used when usage attribute is “GetHandle”.
3.2.3 handle: A handle of a specified object, which is used when the usage attribute is “GetObj”.
3.2.4 Page: Handle of a page that needs to be displayed, and is used when the usage attribute is “GetPageBmp”.
3.2.5 input: Describes a request for an input page, for example, it is possible to specify the display of the contents of one or more layers (the displayable layer is always a layer to which the current role has access authority), Clip The size of the display area can also be specified by specifying the area. Used when the usage attribute is “GetPageBmp”.
3.2.6 output: Describes the page bitmap output method and is used when the usage attribute is “GetPageBmp”.
3.3 Return Value 3.3.1 When the usage attribute is “GetHandle”, when the execution is successful, a sub-element “handle” for recording the handle of the parent-th pos sub-object is added to UOML_RET.
3.3.2 When the usage attribute is “GetObj”, a sub-element “xobj” including the xml representation of handle object data is added to UOML_RET when the execution is successful.
3.3.3 When the usage attribute is “GetPageBmp”, when the execution is successful, the page bitmap is output at the position specified by the sub-element “output”.

4 UOML_SET (setting)
4.1 Attributes: None.
4.2 Sub-elements 4.2.1 Handle: Sets the handle of the object.
4.2.2 xobj: description of the object.
4.3 Return value: None.

5 UOML_INSERT (insert)
5.1 Attributes: None.
5.2 Sub-elements 5.2.1 parent: Parent object handle.
5.2.2 xobj: description of the object.
5.2.3 pos: insertion position.
5.3 Return Value: If the execution is successful, the object represented by the parameter “xobj” is inserted into the parent as the posth sub-object of the parent, and the sub-element “handle” representing the handle of the newly inserted object Is added to UOML_RET.

6 UOML_DELETE (deletion)
6.1 Attributes: None.
6.2 Sub-element 6.2.1 handle: Handle of an object that needs to be deleted.
6.3 Return value: None.

7 UOML_QUERY (search inquiry)
7.1 Attributes: None.
7.2 Sub-element 7.2.1 handle: Document base handle that needs to be queried.
7.2.2 condition: Inquiry condition.
7.3 Return Value: In case of success, a sub-element “handle” representing the handle of the query result and a sub-element “number” representing the number of query results are added to UOML_RET. Each query result can be acquired with UOML_GET.

UOML objects are
Document base (UOML_DOCBASE), document set (UOML_DOCSET), document (UOML_DOC), page (UOML_PAGE), layer (UOML_LAYER), object group (UOML_OBJGROUP), text (UOML_TEXT), IM (EOM) _IML UOML_BEIZER), arc (UOML_ARC), path (UOML_PATH), source file (UOML_SRCFFILE), background color (UOML_BACKCOLOR), foreground color (UOML_COLOR), ROP (UOML_ROP), character size (UOMUL_ROC)

  The definition method will be described below using UOML_DOC, UOML_TEXT, and UOML_CHARSIZE as examples.

1 UOML_DOC
1.1 Attributes: None.
1.2 Sub-elements 1.2.1 metadata: metadata.
1.2.2 pageset: Each page.
1.2.3 fontinfo: Built-in font.
1.2.4 navigation: navigation information.
1.2.5 thread: thread information.
1.2.6 minipage: thumbnail image.
1.2.7 signature: digital signature.
1.2.8 share resource: shared resource.
2 UOML_TEXT
2.1 Attributes 2.1.1 Encoding: Text encoding method.
2.2 Sub-elements 2.2.1 TextData: Text content.
2.2.2 CharSpacingList: Character spacing list for non-uniform spacing.
2.2.3 StartPos: Start position.
3 UOML_CHARSIZE
3.1 Attributes 3.1.1 width: Character width.
3.1.2 height: character height.
3.2 Sub-element: None.

  By analogy according to the above, all UOML objects can be described in the same way. When the document base is operated by an application, a corresponding UOML command is generated according to the XML syntax by the UOML operation and the UOML object, and this UOML command is transmitted to the document base system, that is, a corresponding operation command is transmitted to the document base system. Represents what to do.

For example, a document-based creation operation can be completed with the following command.
<UOML_OPEN create = "true">
<Path val = "f: \\ data \\ docbase1.sep"/>
</ UOML_OPEN>

The document set creation operation can be completed with the following command.
<UOML_INSERT>
<Parent val = “123.456.789” />
<Pos val = "1"/>
<Xobj>
<Docset />
</ Xobj>
</ UOML_INSERT>

  It should be explained that UOML is defined in XML, but in order to look more concise, “<? Xml version =“ 1.0 ”encoding =“ UTF-8 ”?>” And “xmlns : Xsi = "http: // www. w3. An ordinary XML format such as “org / 2001 / XML Schema-instance” ”is omitted at the head, and an implementer familiar with the XML syntax can add it himself / herself during the implementation.

The instruction sequence may be defined by a method other than XML. For example, the above example changes as follows using a method such as PostScript.
1, “f: \\ data \\ docbase1.sep”, / Open
/ docset, 1, “123.456.789”, / Insert

  With the same concept, other types of instruction sequence formats can be defined, and the instruction sequence can be defined not in the text format but in the binary format.

In the following, a specific embodiment of a method that represents one operation for each operation of each object will be introduced. In this embodiment, “UOML_INSERT_DOCSET” represents insertion of a document set, “UOML_INSERT_PAGE” represents page insertion, and each command is defined in the following manner.
UOML_INSERT_DOCSET: One document set is created in the document base.
Attributes: None.
Sub-element:
parent: Document base handle.
pos: Insertion position.
Return Value: If execution is successful, a sub-element “handle” representing the handle of the newly inserted document set is added to UOML_RET.

Thus, the above example changes as follows.
<UOML_INSERT_DOCSET>
<Parent val = “123.456.789” />
<Pos val = "1"/>
</ UOML_INSERT_DOCSET>

  In order to define the instruction format by such a method, it is necessary to define one instruction for each valid operation of each object, and the demerits are complicated.

  In the following, an embodiment for realizing an interface standard by a function call method will be introduced. In this embodiment, the operation command is transmitted to the document base system by calling the interface function of the lower interface from the upper interface. Hereinafter, the present embodiment called UOI will be described using C ++ language as an example.

First, the structure of the UOI return value is defined.
struct UOI_Ret {
BOOT m_b Success;
CString m_ErrInfo;
};

Define the base class for all UOI objects.
class UOI_Object {
public:
enum Type {
TYPE_DOCBASE,
TYPE_DOCSET,
TYPE_DOC,
TYPE_PAGE,
TYPE_LAYER,
TYPE_TEXT,
TYPE_CHARSIZE,
......
};
Type m_Type;

UOI_Object ();
virtual to UOI_Object ();
static UOI_Object Create (Type objType);
};

Next, corresponding to some UOML operations in the “operation operation + operation object” type embodiment, the following several UOI functions are defined.
UOI_RET UOI_Open (char * path, BOOT bCreate, HANDLE * pHandle);
UOI_RET UOI_Close (HANDLE handle, HANDLE db_handle);
UOI_RET UOI_GetHandle (HANDLE hParent, int nPos, HANDLE * pHhandle);
UOI_RET UOI_GetObjType (HANDLE handle, UOI_Object :: Type * pType);
UOI_RET UOI_GetObj (HANDLE handle, UOI_Object * pObj);
UOI_RET UOI_GetPageBmp (HANDLE hPage, RECT rect, void * pBuf);
UOI_RET UOI_SetObj (HANDLE handle, UOI_Object * pObj);
UOI_RET UOI_Insert (HANDLE hParent, int nPos, UOI_Object * pObj, HANDLE * pHandle = NULL);
UOI_RET UOI_Delete (HANDLE handle);
UOI_RET UOI_Query (HANDLE hDocbase, const char * strCondition, HANDLE * phResult);

Thereafter, each UOI object is defined. Still, UOI_Doc, UOI_Text, and UOML_CharSize will be described as examples.
class UOI_Doc: public UOI_Object {
public:
UOI_MetaData m_MetaData;
int m_nPages;
UOI_Page ** m_pPages;
int m_nFonts;
UOI_Font ** m_pFonts;
UOI_Navigation m_Navigation;
UOI_Thread m_Thread;
UOI_MiniPage * m_pMiniPages;
UOI_Signature m_Signature;
int m_nShared;
UOI_Obj * m_pShared;

UOI_Doc ();
virtual to UOI_Doc ();
};

class UOI_Text: public UOI_Object {
public:
enum Encoding {
ENCODE_ASCII,
ENCODE_GB13000,
ENCODE_UNICODE,
. . . . . .
};
Encoding m_Encoding;
char * m_pText;
Point m_Start;
int * m_CharSpace;

UOI_Text ();
virtual to UOI_Text ();
};
class UOI_CharSize: public UOI_Object {
public:
int m_Width;
int m_Height;

UOI_CharSize ();
virtual to UOI_CharSize ();
};

Hereinafter, a method of using the UOI will be described. First, a document base is created.
ret = UOI_Open ("f: \\ data \\ docbase1.sep", TRUE, &hDocBase);

Next, a function for creating a new object is constructed.
HANDLE InsertNewObj (HANDLE hParent, int nPos, UOI_Object :: Type type)
{
UOI_Ret ret;
HADNLE handle;
UOI_Obj * pNewObj = UOI_Obj :: Create (type);
if (pNewObj == NULL)
return NULL;
ret = UOI_Insert (hParent, nPos, pNewObj, &handle);
delete pNewObj;
return ret. m_b Success? handle: NULL;
}

Then build a function to get the object directly.
UOI_Obj * GetObj (HANDLE handle)
{
UOI_Ret ret;
UOI_Object :: Type type;
UOI_Obj * pObj;
ret = UOI_GetObjType (handle, &type);
if (! ret.m_bSuccess)
return NULL;
pObj = UOI_Obj :: Create (type);
if (pObj == NULL)
return NULL;
ret = UOI_GetObj (handle, pObj);
if (! ret.m_bSuccess) {
delete pObj;
return NULL;
}
return pObj;
}

In the method of defining one interface function for each operation of each object, an operation command for inserting a document set is transmitted to the document base system by calling the interface function of the lower interface from the upper interface in the following manner.
UOI_InsertDocset (pDocbase, 0);

In a method of encapsulating each object class (for example, a document base class), an executable operation of the object is defined as a method of the class. For example,
class UOI_DocBase: public UOI_Obj
{
public:
/ *!
* \ Brief create document base * \ param szPath: full path of document base * \ param bOverride: whether to overwrite the original file * \ return UOI_DocBase object * /
BOOT Create (const char * szPath, bool bOverride = false);
/ *!
* \ Brief open document base * \ param szPath: full path of document base * \ return UOI_DocBase object * /
BOOT Open (const char * szPath);
/ *!
* \ Brief Close document base * \ param None * \ return None * /
void Close ();
/ *!
* \ Brief Get role list * \ param None * \ return UOI_RoleList object * \ sa UOI_RoleList
* /
UOI_RoleList GetRoleList ();
/ *!
* \ Brief document-based storage * \ param szPath: full path of the document base to be stored * \ return none * /
void Save (char * szPath = 0);

/ *!
* \ Brief Insert document set * \ param nPos: Insert position of document set * \ return UOI_DocSet object * \ sa UOI_DocSet
* /
UOI_DocSet InsertDocSet (int nPos);
/ *!
* \ Brief Get document set of specified index * \ param nIndex: index number of document list * \ return UOI_DocSet object * \ sa UOI_DocSet
* /
UOI_DocSet GetDocSet (int nIndex);
/ *!
* Get the total number of \ brief document sets * \ param None * \ return Number of document sets * /
int GetDocSetCount ();
/ *!
* \ Brief Document base name setting * \ param nLen: Length of document base name
* \ Param szName: document name * \ return None * /
void SetName (int nLen, const char * szName);
/ *!
* \ Brief Get document base name length * \ param None * \ return length * /
int GetNameLen ();
/ *!
* \ Brief Get document base name * \ param None * \ return Document base name * /
const char * GetName ();
/ *!
* \ Brief Get document base id length * \ param None * \ return length * /
int GetIDLen ();
/ *!
* \ Brief Get document base id * \ param None * \ return id
* /
const char * GetID ();
//! Constructor function UOI_DocBase ();
//! Destructor function virtual ~ UOI_DocBase ();
};

As described above, the operation command for inserting the document set is transmitted to the document base system by calling the interface function of the lower interface from the upper interface in the following manner.
pDocBase. InsertDocset (0);

  Depending on the same method, different types of interface standards may be designed for applications developed in various programming languages such as Java (registered trademark), C #, VB, and Delphi.

  The interface standard includes a specific operating system (for example, WINDOWS (registered trademark), UNIX (registered trademark) / LINUX (registered trademark), MAC (registered trademark) OS, SYMBIAN (registered trademark)) or a specific hardware platform (for example, If the features related to x86 CPU, MIPS, POWER PC, etc. are not included, this interface standard will be cross-platform and applications and document-based systems running on different platforms will unify the same interface standard. It becomes possible to use it, and it is possible to call a document-based system running on another platform from an application running on one platform and perform the corresponding operation.For example, the application is located on the client side using a PC and Windows operating system, and the document-based system is located on the server side using a large machine and a LINUX operating system, but still local from the application. Similar to the call to the document-based system, the document-based system at the server can be called to perform corresponding document operations.

  It is also possible that this interface standard is independent of the programming language if the interface standard does not include features associated with a particular programming language. As can be seen from the above, in the instruction sequence method, an interface standard unrelated to the platform and programming language can be easily constructed, and versatility is enhanced. In particular, when an instruction sequence is configured in XML, there are XML generation analysis tools that can be easily acquired in various different platforms and different programming languages. Therefore, this interface standard has excellent cross-platform properties and programming languages. Not only is there irrelevance, it is also very convenient for engineers to develop upper interface units and lower interface units.

In the above, a method for realizing a plurality of interface standards is mentioned, and more interface standards designed based on a similar concept are also included in the protection scope of the present invention.
As should be understood, an operation command may be added or simplified on the above-described embodiment based on the same concept. In particular, when the document model is simplified, the operation command is correspondingly simplified. In the simplest case, there are only a few operation commands for creating a document, creating a page, and creating each layout object.

[Document Operation Processing]
With reference to FIG. 1, the operation process of the document processing system according to the preferred embodiment of the present invention will be described.

  The application is an application including an interface unit that conforms to the interface standard, such as an Office application, content management, resource collection, and the like. If any application wants to manipulate the document, the command is transmitted to the document-based system according to the method, and the document-based system completes a specific operation process based on the command.

  The document-based system can freely store and organize document-based data. For example, all documents based on one document may be stored in one disk file. One document is made to correspond to one disk file, and a multi-document organization is realized by using the file system function of the operation system. One page may correspond to one disk file, and the operating system may not be used completely, leaving space on the disk and managing disk tracks and sectors directly. Good. The storage format of the document base data may be saved in a binary format, XML, or binary XML. As for the page description language (method for defining objects such as text, graphics, and images on the page), PostScript, PDF, or SPD (page description language used by the book production company) may be adopted, and of course, a unified interface. Any customized page description language may be employed as long as it conforms to the standard.

  For example, document base data may be described in XML. If the document model is hierarchical, a corresponding XML tree can be established in full contrast. Add a node to the XML tree when executing the create operation, delete the corresponding node when executing the delete operation, set the attribute of the corresponding node when executing the setting operation, and extract the attribute of the corresponding node when executing the acquisition operation And scans and searches related nodes when executing the inquiry operation.

  Hereinafter, the embodiment will be further described.

  1. Each object is described in XML. That is, a corresponding XML tree is established for each object. For objects with relatively simple attributes, there is only a root node in the corresponding XML tree, and for objects with relatively complex attributes, there are also sub-nodes in the corresponding XML tree. For a specific description method, reference may be made to the description of defining an operation object in the XML.

  2. When a new document base is created, an XML file whose root node is a document base object is newly created.

  3. Each time an object (for example, a text object) is inserted into the document base, an XML tree corresponding to the object is inserted under a parent node (for example, a layer) at the insertion position. Thus, each document-based object has a corresponding node in the XML tree whose document base is the root node.

  4). When an object is deleted, the node corresponding to this object and all subnodes of the node are deleted. In the deletion process, the scan starting from the leaf node is performed from bottom to top.

  5). When the object attribute is set, the attribute of the node corresponding to this object is set in the attribute. When this attribute is represented by a sub-node attribute, the attribute of the corresponding sub-node is set.

  6). When an object attribute is acquired, a node corresponding to the object is accessed, and the attribute of the object is acquired by the attribute and subnode of the node.

  7. If the handle of the object is obtained, the XML path of the node corresponding to this object is returned.

  8). When an object (eg, page) is copied to a specified location, the entire subtree starting from the node corresponding to this object is copied under the parent node (eg, document) corresponding to the target location. When objects are copied to other document bases, the objects cited in this subtree (eg, embedded fonts) need to be copied together.

  9. When a layout information acquisition command is executed, first, a blank bitmap in the specified bitmap format whose size is the same as the specified area is generated, and then all layout objects on the specified page are scanned and within the specified area. If the layout object is located (including only a part of the layout object), the meaning is interpreted and reflected in the layout accordingly. Although the specific process is relatively complicated and specialized, it belongs to the range of the conventional RIP technology, and therefore the description thereof is omitted here.

[Document Security Processing]
When creating the roll object, a random public key and private key pair (for example, 512-bit RSA key) is generated, the public key is stored in the roll object, and the private key is returned to the application.

  When the application logs in, a random data block (for example, 128 bytes) is generated, and the data is encrypted with the public key of the corresponding role object and transmitted to the application. When the application decrypts it and compares and verifies it, if it is correct, it means that the application has a private key corresponding to the role, and login is successful. As a precaution, this authentication process may be repeated three times, and login is successful only after three passes.

  To sign an object is to sign a subtree starting from its corresponding node. In order to prevent the influence of the specific physical storage method from affecting the signature, the validity of the signature is changed by logically equivalent changes (for example, a change in the storage position leads to a change in the corresponding pointer). It is necessary not to affect.

  The normalization method scans each node of the subtree having the target object as a root node (that is, the target object and each subobject thereof) with depth priority, and sequentially calculates the normalization result of each node according to the scanning order and combines them. Including doing.

  Here, the method of calculating the normalization result of a node having a sub-tree first calculates the HASH value of the number of sub-nodes of this node, and then sequentially calculates the HASH value of this node type and each attribute thereof, This includes joining next to the HASH value of the number of subnodes of the node according to the order, and then calculating the HASH value of the joining result to obtain the normalization result of the node. When it is necessary to sign an object quoted at a node in the subtree together, the object quoted at the node may be processed as a subnode of the node by the same method as described above.

  Since the process of calculating the HASH value and signing with the private key of the role after normalization can be performed using the conventional technique, the description thereof is omitted here.

  In the normalization process, the method of calculating the normalization result of a node is to combine the number of subnodes of this node, the type and each attribute thereof with a separator according to the order, calculate the HASH value of this combined result, Obtaining a normalized result may be included. The method of calculating the normalization result of a node is to combine the number of subnodes of this node, the type, and the length of each attribute with a separator according to the order, and combine the number of subnodes, the type, and each attribute, Obtaining a normalization result may be included. In other words, the method of calculating the normalization result of the node is the original value of the number of subnodes, the type, each attribute, and the number of subnodes / type / the length of each attribute (selectable) for a node in the tree or It includes combining values after a specific transformation (for example, HASH, compression) according to a predetermined order (directly combined or combined with a separator).

  The predetermined order includes the length of the number of subnodes, the length of the type, the length of each attribute, the number of subnodes, the type, and an arbitrary predetermined arrangement order of the attributes.

  In addition, for the scanning of each node of the subtree, either depth priority scanning or width priority scanning may be employed.

  It is not difficult to provide various variants of the above scheme. For example, the number of subnodes of each node is combined with a separator according to a depth-first order, and combined with the normalization result of other data of each node. That is, as long as the number of subnodes, the type, and each attribute of all the nodes of the subtree are arranged by a predetermined method, it belongs to the modification of this embodiment.

  When setting authority for an object, the simplest method is to simply record the authority for the object (and its sub-objects) of each role and compare it with the access in each role in the future. , Including proper operation and reporting error information back if it does not fit the authority. Further preferred implementations include encrypting the corresponding data and controlling the authority with a key. If the role does not have a corresponding key, there is no corresponding authority. Such a scheme is more resistant to attacks. The specific plan is as follows.

a) There is a PKI key pair corresponding to a protected data area (usually a subtree, corresponding to an object and all its sub-objects), and this data area is encrypted using the encryption key .
b) A decryption key is given to a role having read authority, and the role can decrypt this data area using this key, and read these data correctly.
c) An encryption key is given to a role with write authority, and the role can use this key to encrypt the corrected data and write the data in the area accurately.
d) Since the efficiency of encryption / decryption of PKI is relatively low, the data area may be encrypted using a symmetric key so as to improve operation efficiency. The symmetric key is encrypted with the encryption key, and the encrypted key data is decrypted with the decryption key, thereby obtaining an accurate symmetric key. In order to prevent a role having only read authority from acquiring a symmetric key and using it to modify the data, a digital signature may be performed on the data area using an encryption key. Each time a role with write authority modifies the data area, a new signature is used to ensure that data is not tampered with a role without write authority.
e) When an encryption key or a decryption key is given to a role, the encryption key or the decryption key may be encrypted after being stored using the public key of the role. As a result, the encryption key or the decryption key cannot be extracted without the private key of the role.

  What should be explained is the document security technology described in the present invention, eg, role-based authority management, role authentication method, multi-role login, tree structure normalization technology, fine-grained authority management unit, encryption-based authority The setting and the like can be applied not only to the document processing system according to the present invention but also to a wide variety of other applications.

[Management for layer]
In the present invention, there is provided a technical solution of “no modification only for addition” so that the document processing system can well simulate the characteristics of paper. That is, each application only adds new content on top of the current document content, and does not modify or delete existing content. This makes the pages of the document look like paper, and different people can write on the paper using different pens, but no one can modify or delete existing content. A specific method is as follows. When editing a document generated by another application, each application adds a new layer above the current document, and puts all the newly edited contents in this application on this layer. Do not modify or delete the contents of each layer. In this way, each layer of each document is managed and maintained by only one application, but the layer cannot be edited by other applications. Since the current society is operated on the basis of paper, the document processing system can meet the current application needs as long as it meets the characteristics of paper and has sufficient practical value.

  To ensure that the contents of each layer are not modified / deleted after the contents of each layer are generated, the digital signature object of each layer may be used. The digital signature may sign the contents of this layer. Preferably, the contents of this layer and all layers generated before this layer are signed together. Even after signing, further editing, such as comments on the document, is not hindered. The signature is still valid unless the new content is located in a new layer and each existing layer is modified or destroyed at the time of signing, but the signer is responsible only for the content before the signature, and the content after the signature Not responsible for. This is a technical proposal that is very suitable for application needs and has considerable practical value. On the other hand, in other conventional techniques, editing after signature is not allowed, or the signature is destroyed after editing (despite editing without adding only).

  In the above technical solution, the existing contents of the document are not allowed to be modified, and only the layout level editing can be performed when the modification is necessary without considering the compatibility with the paper characteristics and the digital signature problem. In other words, editing (addition, deletion, modification) on each layout object does not affect other layout objects (the general-purpose document model is built on the basis of the visible part, and a large amount of invisible relationships between layout objects can be established. Because it does not include any modification to the layout object, for example, if one character is deleted, the right character automatically moves to the left without causing a corresponding adjustment to the other layout object. Without leaving a blank in that position.) When the user intends to edit the existing contents of a document by the original method, the following technical solution can well satisfy this application need. For this method, when the application completes the initial editing, in addition to creating a new layer and saving the current editing content, the source file (the complete relationship between each object is recorded in the application's own format) File, eg, a .doc file). If it is necessary to continue editing this time, the source file is taken out from the document and edited using the source file. After the editing is completed, the layer managed by the application is deleted, the content of the layer is newly generated, and the newly modified source file is continuously incorporated into the document.

  The specific method includes the following steps.

1. When the application processes a document for the first time, it creates a new layer, inserts a layout object corresponding to the new edited content into the newly created layer, and creates the new edited content (ie source file) in its own format. Store separately.
2. Create a new source file object as a sub-object of the document object. The source file object is used for incorporating a source file (for example, incorporating the whole in the form of binary data) and recording which layer corresponds to the source file object.
3. When the document is edited again using the same application, the corresponding source file is extracted from the corresponding source file object.
4). Continue to edit the contents of the layer using the source file. Since the format of the source file is the application's own format, the contents of the layer can be continuously edited by the function of the application.
5. After the editing is completed again, the contents of the layer are updated based on the newly edited result (for example, by a method of generating again after erasing all), and the newly corrected source file is newly incorporated into the document object.
6). In this way, the existing contents of the document can be edited by the original method using the original application.

  By adopting the above technical proposal, the interoperability of documents can be realized to the maximum. If the application and document adopt the technology of the present invention on the premise of sufficient security authority, the following functions can be realized.

1. Any document can be opened, displayed and printed accurately in any application.
2. For any document, any application can add any content and the existing signature of the document is not destroyed.
3. Any application can perform layout-level editing on the existing contents of a document, assuming that no existing signature of the document needs to be considered for any document (no signature or signature but allows destruction).
4). For any document, the original editing application for the existing content of the document can be edited normally.

  As can be seen from the above, the management of the layers of the present invention provides tremendous convenience for document management, interoperability, and security settings.

  Hereinafter, the operation process will be described by taking application A as a document and application B as an example. In this embodiment, UOI is used as an interface standard.

1. Document base c: \ sample \ mydocbase. Application A sends a command to create a sep and store its handle in hDocBase.
UOI_Open ("c: \ sample \\ dococbase.sep", TRUE, &hDocBase);
2. The application A transmits a command for creating a new document set in the document base hDocBase and storing the handle in the hDocSet.
hDocSet = InsertNewObj (hDocBase, 0, UOI_Obj :: TYPE_DOCSET);
In the present embodiment, there is only one document set, that is, the first document set in this document base.
3. The application A transmits a command for creating a new document in the document set hDocSet and storing the handle in the hDoc.
hDoc = InsertNewObj (hDocSet, 0, UOI_Obj :: TYPE_DOC);
In this embodiment, there is only one document in the document set, that is, the first document.
4). The application A transmits a command for newly creating a page having a width w and a height h in the document hDoc and storing the handle in the hPage.
UOI_Page page;
page. size. w = w;
page. size. h = h;
UOI_Insert (hDoc, 0, & page, &hPage);
In this embodiment, this document has only one page, that is, the first page.
5. Application A sends a command to create a new layer in page hPage and save its handle in hLayer.
hLayer = InertNewObj (hPage, 0, UOI_Obj :: TYPE_LAYER);
In this embodiment, this page has only one layer, that is, the first layer.
6). Application A sends a command to set the character size to s.
UOI_CharSize charSize;
charSize. m_Width = charSize. m_Height = s;
UOI_Insert (hLayer, 0, & charSize)
In the present embodiment, the first layout object in this layer is a character size object.
7). Application A transmits a command for inserting the character string “The meaning of the calligraphy is written in the direction” at the coordinates (x1, y1).
UOI_Text text;
text. m_pText = Duplicate (“Calligraphy ’s intentions are written and used”);
text. m_Encoding = UOI_Text :: ENCODE_GB13000;
text. m_Start. x = x1;
text. m_Start. y = y1;
UOI_Insert (hLayer, 1, &text);
In the present embodiment, the second layout object in this layer is a text object.
8). Application A sends a command to close document base hDocBase.
UOI_Close (hDocBase);
9. Document base c: \ sample \ mydocbase. Application B sends a command to open sep and save its handle in hDocBase.
UOI_Open (“c: \ sample \\ dococbase.sep”, FALSE, &hDocBase);
10. The application B transmits a command for acquiring the pointer of the first document set of the document base hDocBase and storing the handle in the hDocSet.
UOI_GetHandle (hDocBase, 0, &hDocSet);
11. The application B transmits a command for acquiring the pointer of the first document of the document set hDocSet and storing the handle in the hDoc.
UOI_GetHandle (hDocSet, 0, &hDoc);
12 The application B transmits a command for acquiring the pointer of the first page of the document hDoc and storing the handle in the hPage.
UOI_GetHandle (hDoc, 0, &hPage);
13. Application B obtains a bitmap for displaying this page.
UOI_GetPageBmp (hPage, rect, buf);
14 The application B transmits a command for acquiring the pointer of the first layer of the hPage and storing the handle in the hLayer.
UOI_GetHandle (hPage, 0, &hLayer);
15. The application B transmits a command for acquiring the handle hObj of the first layout object.
UOI_GetHandle (hLayer, 0, &hObj);
16. The application B transmits a command for acquiring the type of hObj.
UOI_GetObjType (hObj, &type);
17. Application B finds this is a character size object and obtains this object.
UOI_GetObj (hObj, &charSize);
18. Application B enlarges the character height by a factor of two.
charSize. m_Height * = 2;
UOI_SetObj (hObj, &charSize);

  Application B acquires and displays the page bitmap again. At this time, “Letter of the student's intention is written on the screen” is a long character on the screen.

  Hereinafter, with reference to FIG. 10, an embodiment in which an operation is performed in the document processing system according to the present invention will be described. In this embodiment, an application requests an operation on a document via a uniform interface standard (eg, UOML interface). There can be different types of document-based systems from different manufacturers, but different types of document-based systems from different manufacturers can be used in conjunction with the application, since it is suitable for application developers to the same interface standard. Red Office, OCR, a web page generation application, a score editing application, a book production reader, an Office editing application, and other readers instruct the operation to the document base system via the UOML interface. There may be a plurality of document base systems. FIG. 10 shows the document base system 1, the document base system 2, and the document base system 3. The document base system operates a document conforming to the general-purpose document model according to a unified standard command from UOML, for example, creates, saves, displays, and expresses a document. In the present invention, different applications can call the same document-based system at the same time or different times, and the same application can call different document-based systems at the same time or different times.

  According to the present invention, the application layer and the data processing layer are separated, and the same document is widely used between different applications, and excellent document interoperability is achieved between different applications.

  According to the present invention, the industry becomes a division of labor, duplication development is reduced, and more specialized, complete and accurate. Since all the basic operations on the document are processed in the document-based system, it is not necessary to be developed repeatedly in each application. A document-based system is developed by a specialized manufacturer to ensure the expertise, completeness, and accuracy of related technologies, and the application manufacturer and user can select the optimal document-based system manufacturer. Consistency can be ensured.

  According to the present invention, a management mechanism for multi-documents and thus a large number of documents can be provided, documents can be effectively organized, convenient for searching, inquiring and storing, and convenient for incorporating relatively strong information security mechanisms. Become.

  According to the present invention, an excellent security mechanism is provided, a multi-role can be set, and the authority of each role can be set to a fine granularity. The fine granularity here has two meanings, and the authority can be set for the whole document or a minute part of the document, but not only the traditional three-stage authority that does not allow read / write access. , Can set various kinds of authority.

  The present invention encourages innovation and reasonable competition. After becoming a reasonable division of industry, each document-based system manufacturer and each application manufacturer will compete in their own fields without the situation of monopolizing the application with a document format such as Microsoft Word. Become. In order to attract users, each document-based system manufacturer may add a new function in addition to the standard. So standards do not tie innovation.

  According to the present invention, optimization of performance is convenient and more excellent portability and expandability are provided. Any platform with any performance can follow a similar call interface, so performance can be constantly optimized and migrated to a different platform without changing the interface standard.

  The above are only preferred embodiments of the present invention, and do not limit the protection scope of the present invention. Various modifications, equivalent switching, improvements and the like made within the spirit and principle of the present invention should all be included in the protection scope of the present invention.

It is a block diagram which shows the structure of the document processing system by this invention. It is a figure which shows the structure of the general purpose document model by preferable embodiment of this invention. It is a figure which shows the structure of the document base object in the general purpose document model of FIG. It is a figure which shows the structure of the document base auxiliary | assistant object in the document base object of FIG. It is a figure which shows the structure of the document set object in the document base object of FIG. It is a figure which shows the structure of the document object in the document set object of FIG. It is a figure which shows the structure of the page object in the document object of FIG. It is a figure which shows the structure of the layer object in the page object of FIG. It is a figure which shows the structure of the layout object in the layer object of FIG. It is a figure which shows the process of the document processing system which makes a UOML interface an example.

Claims (37)

A system for processing documents,
An application layer that sends standard directives for manipulating documents that conform to the generic document model;
A document-based system that receives the standard command and manipulates document data based on the standard command;
A document processing system comprising: The application layer includes an upper interface unit, and the application layer transmits the standard command via the upper interface unit;
The system according to claim 1, wherein the document-based system includes a lower interface unit, and the document-based system receives the standard command via the lower interface unit.   The system according to claim 1, wherein the document-based system returns an execution result to the application layer.   The system of claim 1, further comprising a storage layer for storing document data generated by the document-based system.   The system according to claim 1, wherein an application in a different application layer instructs an operation to the same document base system at the same time or different times.   The system according to claim 1, wherein the same application in the application layer instructs an operation to different document-based systems at the same time or different times. The generic document model includes one or more document objects, one or more page objects, and any number of layout objects;
Each document object includes one or a plurality of page objects having an order of front and back, each page object includes an arbitrary number of layout objects,
The system according to claim 1, wherein the layout object includes any one or a combination of a text object, a graphic object, and an image object. The generic document model further includes one or more document base objects;
The system of claim 7, wherein the document base object includes one or more document objects. The generic document model further includes one or more document set objects;
The system of claim 8, wherein the document base object includes one or more document set objects, and the document set object includes one or more document objects. The generic document model further includes one or more layer objects;
8. The system of claim 7, wherein the page object includes one or a plurality of layer objects having a front and back order, and the layer object includes an arbitrary number of layout objects.   The document object further includes one or a combination of any number of metadata objects, any number of navigation objects, any number of thread objects, and any number of thumbnail image information objects. 8. The system according to 7.   The system according to claim 7, wherein the general-purpose document model further includes an arbitrary number of font objects and an arbitrary number of image objects shared by each document object and each page object.   The layout object is one of a status object, a script object, a plug-in object, a built-in object, a navigation object, a bookmark object, a link object, a streaming media object, a binary data stream object, and a hyperlink object, or The system of claim 7, further comprising a plurality of combinations. The generic document model further includes role objects, each role having different permissions to access other objects;
The system according to claim 7, wherein the authority includes one or a combination of read / write permission / write permission / copy permission / print permission from each role. A method for processing a document, comprising:
A process in which the application layer sends standard commands for manipulating documents that conform to the generic document model;
A process in which a document-based system manipulates document data based on the standard directive;
A method comprising the steps of:   The method according to claim 15, further comprising the step of returning the execution result of the step of manipulating the document data to the application layer. The general-purpose document model includes a document object, a page object, and a layout object,
The process of operating
The process of creating or deleting a document object;
The process of creating or deleting a document page object;
16. The method of claim 15, comprising creating or deleting a page layout object. The generic document model further includes a document base object and a document set object;
The process of operating
Creating or deleting document base objects; and
The method of claim 15, further comprising creating or deleting a document-based document set object. The generic document model further includes a layer object, the page object includes one or more layer objects, the layer object includes one or more layout objects,
The method of claim 15, wherein the step of manipulating further comprises creating or deleting a layer object of the page. The process of operating
The process of obtaining the attributes of each object of the general-purpose document model,
The method according to any one of claims 15 to 19, further comprising the step of modifying attributes of each object of the general-purpose document model.   20. A method as claimed in any one of claims 15 to 19, wherein the step of manipulating further comprises obtaining a page bitmap of a page object. The process of transmitting comprises
The interface layer generates commands from the application into standard commands according to a predetermined command format,
16. The method according to claim 15, further comprising the step of the interface layer generating a standard command by calling a predetermined interface function corresponding to the command based on the command from the application.   The method according to claim 22, wherein the predetermined command format includes an operation action + an operation object. The process of operating
The method according to claim 15, further comprising: searching for an object matching the condition from the document data according to a condition set by the user through the application layer.   The method according to claim 24, wherein the condition includes a combination of one or more attributes of a text object, a typeface object, a character size object, and a color object included in the general-purpose document model.   An application comprising an interface unit that transmits a standard command for manipulating a document conforming to a general-purpose document model. The generic document model includes one or more document objects, one or more page objects, and any number of layout objects;
Each document object includes one or a plurality of page objects having an order of front and back, each page object includes an arbitrary number of layout objects,
The application according to claim 26, wherein the layout object includes any one or a combination of a text object, a graphic object, and an image object. An interface unit that receives standard commands for manipulating documents that conform to the general-purpose document model;
A processing unit for manipulating document data based on the standard command;
A document-based system characterized by including:   29. The document-based system of claim 28, further comprising a storage unit that stores document data. The generic document model includes one or more document objects, one or more page objects, and any number of layout objects;
Each document object includes one or a plurality of page objects having an order of front and back, each page object includes an arbitrary number of layout objects,
The document-based system according to claim 28, wherein the layout object includes any one or a combination of a text object, a graphic object, and an image object. An upper interface unit that sends standard commands for manipulating documents that conform to the generic document model;
A lower interface unit for receiving the standard command;
An interface layer characterized by comprising:   The interface layer according to claim 31, wherein the lower interface unit determines whether the received command is a standard command and analyzes the standard command. The generic document model includes one or more document objects, one or more page objects, and any number of layout objects;
Each document object includes one or a plurality of page objects having an order of front and back, each page object includes an arbitrary number of layout objects,
The interface layer according to claim 31, wherein the layout object includes any one or a combination of a text object, a graphic object, and an image object. A system for processing documents,
An application layer having at least one application;
An interface layer for transmitting a standard command for operating a document conforming to the general-purpose document model from the application layer;
A document-based system for manipulating document data according to the standard command;
A system characterized by including.   The system according to claim 34, wherein the document-based system returns an execution result to the application layer through the interface layer. The interface layer includes an upper interface unit and a lower interface unit;
The application layer sends a standard command to the lower interface unit via the upper interface unit,
The system of claim 34, wherein the document-based system receives standard commands via a lower interface unit. The generic document model includes one or more document objects, one or more page objects, and any number of layout objects;
Each document object includes one or a plurality of page objects having an order of front and back, each page object includes an arbitrary number of layout objects,
The system according to claim 34, wherein the layout object includes any one or a combination of a text object, a graphic object, and an image object.

Images