Method and apparatus for declarative updating of self-describing, structured documents

Abstract

The present invention includes a method and device for updating a self-describing, structured document. A further aspect of the present invention is enabling client-based modification of the document. Additional aspects of the present invention are described in the claims, specification and drawings.

Claims

We claim:

1. A method for updating of a self-describing, structured document, the method including:

receiving a request identifying a starting document and specifying a document type to be generated from the starting document;

accessing at least first and second declarative transformations corresponding to the starting document and the specified document type;

applying the first declarative transformation to the starting document, producing a resulting document of the specified document type;

applying the second declarative transformation to the resulting document, producing character string data including a plurality of

path specifications for nodes in the resulting document;

starting values copied from the starting document for at least some of the nodes; and

editable values for at least some of the nodes;

responding to the request with the character string data;

receiving an updated version of the character string data; and

producing an updated resulting document corresponding to the updated version of the character string data.

2. The protocol of claim 1, wherein the request further includes a document ID.

3. The method of claim 1, wherein a document ID is implied by prior state information.

4. The method of claim 3, further including accessing the starting document based on the document ID.

5. The method of claim 4, wherein the path specifications are compliant with any version of an XPath standard.

6. The method of claim 3, wherein the starting document is represented by a document-object-model (DOM) data structure in memory.

7. The method of claim 6, wherein the path specifications are compliant with any version of an XPath standard.

8. The method of claim 1, wherein the path specifications are compliant with any version of an XPath standard.

9. The method of claim 1, wherein the specified document type corresponds to a schema, further including validating the updated resulting document against the schema.

10. The method of claim 9, wherein the specified document type and a chosen trading partner correspond to a set of business processing rules, further including validating the updated resulting document against the set of business processing rules.

11. The method of claim 10, wherein the schema is compliant with any version of a SOX standard.

12. The method of claim 10, wherein the business-processing rules are Schematron-compliant.

13. The method of claim 9, wherein the schema is compliant with any version of a SOX standard.

14. The method of claim 1, further including:

displaying for a user a graphical interface providing the user with results of the second declarative transformation and adapted to interact with the user and generate the updated version of the character string.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to commonly assigned, co-pending U.S. patent application Ser. No. 09/794,302, filed on Feb. 27, 2001, entitled A METHOD AND APPARATUS FOR VIEWING ELECTRONIC COMMERCE-RELATED DOCUMENTS (CMRC 1002-1), by inventors Andrew Everett Davidson, Kelly Lane Schwarzhoff, Gunawan Herri, Changyi Zhu, Ari Krish, Muljadi Sulistio, and Sun Keun Lee, which is hereby incorporated by reference as if fully set forth.

This application is further related to the following commonly assigned, co-pending applications filed on Dec. 18, 2001, the same day as the present application: U.S. patent application Ser. No. 10/026,663, xCBL MAILBOX METHODS AND DEVICES (CMRC 1010-1), by inventors Muljadi Sulistio, Yang Wei, Kelly Lane Schwarzhoff, Yuan Din, Sun Lee and Andy Yang; U.S. patent application Ser. No. 10/026,366, METHOD AND APPARATUS FOR DECLARATIVE ERROR HANDLING AND PRESENTATION (CMRC 1008-1), by inventors Muljadi Sulistio, Yang Wei, Kelly Lane Schwarzhoff and Yuan Din; and U.S. patent application Ser. No. 10/026,681, METHOD AND APPARATUS FOR GENERIC SEARCH INTERFACE ACROSS DOCUMENT TYPES (CMRC 1009-1), by inventors Muljadi Sulistio, Yang Wei, Kelly Lane Schwarzhoff, Yuan Din, Sun Lee and Andy Yang. These applications filed on the same day are hereby incorporated by reference as if fully set forth.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure is it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

Electronic commerce between businesses has gained substantial momentum. Electronic marketplaces and XML or similar documents have begun to replace traditional EDI formats for commerce-related documents. Still, many businesses, particularly small and medium-sized businesses, have not adopted automated EDI or XML document processing. Whatever their size, many businesses face the prospect of an expedited implementation of EDI or XML document processing. It remains easier for large trading partners to generate XML or similar documents than it is for small to medium-sized businesses to adopt the technology needed to process them. In addition, a full scale conversion to EDI or XML transaction processing may involve far more documents than a business can practically convert in a workable time frame or on a reasonable budget.

One problem with the implementation of EDI or XML transaction processing is the complexity and cost of procedural programming to process business documents. Procedural programming, otherwise known as hard coding, requires much effort to describe document transformations and manipulations in procedural terms, using programming languages such as Java and C++. This effort translates into time for implementation and cost of implementation.

In some domains or problem spaces, declarative programming has been introduced. It is generally hoped that so-called declarative programming can make program customization accessible even to non-programmers. At the same time, it has been recognized that declarative programming is best when applied to a limited domain. Accordingly, declarative approaches are narrow and tailored, not generally applied.

Therefore, in the domain of exchanging self-defining, structured documents, it is desirable to develop declarative methods and components for simplifying the handling of documents. Declarative methods and components can improve interactions with users, particularly in the areas of producing documents, presenting error messages and searching for documents.

SUMMARY OF THE INVENTION

The present invention includes a method and device for updating a self-describing, structured document. A further aspect of the present invention is enabling client-based modification of the document. Additional aspects of the present invention are described in the claims, specification and drawings.

BRIEF DESCRIPTION OF FIGURES

FIG. 1 is an overview of the user interface for an xCBL mailbox.

FIG. 2 is a sample screen display of a folder list, as part of a user interface.

FIG. 3 is a sample screen display for a list of documents within a folder, as part of a user interface.

FIG. 4 is a sample screen display for a indicating a reply document type.

FIG. 5 is the sample screen display for searching on a selected document type, as part of a user interface.

FIG. 6 is a block diagram of activities involving two trading partners communicating through a document exchange system.

FIG. 7 is an application flow providing additional detail of activities involving two trading partners communicating through a document exchange system.

FIG. 8 is a block diagram of a self-describing, structured document.

FIG. 9 illustrates participants in a marketplace.

FIG. 10 is a database schema for a data structure that may be used to practice aspects of the present invention.

FIG. 11 is one architecture for software components that handle generic documents.

FIG. 12 is a user interface and processing diagram, including validation of user created documents.

FIG. 13 is a user interface for replying to a request for quote with a quote.

FIG. 14 is an action sequence for replying to a document.

FIG. 15 is a sequence diagram illustrating use of a servlet to control responses to a user action request.

FIG. 16 is a sequence diagram illustrating interaction between a servlet, interpreter and data structure engine, in response to data from a user.

FIG. 17 is a block diagram illustrating posting of data and some of the components involved in responding.

FIG. 18 is a simplified flow chart for a method of updating a self-describing, structured document.

FIG. 19 illustrates a protocol for updating a self-describing, structured document corresponding to one of a plurality of document schemas.

FIG. 20 is a flowchart overview of validation.

FIG. 21 is a flowchart overview of a method of searching a plurality of self-describing structure documents.

FIG. 22 a flowchart overview of preparing documents for searching.

FIGS. 23-26 illustrate data tables used to prepare documents for searching.

DETAILED DESCRIPTION

The following detailed description is made with reference to the figures. Preferred and alternative embodiments are described to illustrate the present invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows.

FIG. 1 depicts a user interface view of a system for handling generic business documents exchanged among trading partners. This illustrates an environment in which aspects of the present invention may be practiced. A user of a document exchange system uses a computer, terminal or other workstation to access a login screen 111. Standard login and authentication protocols can be followed. After a successful login, a user is presented with an initial mailbox screen 112. FIG. 2 depicts a sample initial screen. The user's choices from the initial screen may include folder management 121, document searching 122, listing of documents in the selected folder 123 or selection of a particular document type of interest 124. Some of these options may be omitted or others may be added to a system. The folder management screen 121 provides typical functions for creating, deleting, renaming folders, etc. The document search screen 122 allows a user to select a document type and search on various criteria that are adapted to the selected document type. FIG. 5 depicts a sample search screen. The list of documents in a folder screen 123 can be reached from either the initial screen or from a document search screen. It provides various information about documents in a folder, as shown in FIG. 3. The document type selection screen 124 can be implemented to allow a user to create a document from scratch. When a user selects a particular type of document to compose, the system can respond with a document compose screen 134 that includes the fields to be completed.

From the list of documents in a folder screen, the user can export a document 131, read it 132, or use it as a basis for a new document 133, either by replying to or copying the base document. The document may be exported as an XML, PDF, CSV, HTML or other-formatted document. Standard or user-supplied export filters can be implemented.

The processing of a user request to view a document can be understood by reference to the co-pending application for A Method and Apparatus for Viewing Electronic Commerce-Related Documents at pp. 5-52 and the figures cited therein. In general, a series of style sheets can be constructed for displaying documents. These style sheets may be written in XSLT, or another transformation language applicable to the data type of the documents. A series of style sheets may be written, from generic to highly customized. A rule selector can be used to select among the available style sheets based on criteria such as document type, marketplace identity, sender identity, receiver identity, portal identity or other selected criteria. A directory tree, database or other data structure can be used to access style sheets based upon the criteria used.

A user can select among document types for a resulting reply document 133. The available document types for a resulting reply document depend on the document type of the starting document type, for instance a starting document selected from a list of documents 123. FIG. 4 is a sample screen from which a user selects a document type 442 for a resulting reply document. The reply document type can be the same as the starting type, for instance when a user is copying and reusing a previous order as a template. The trading partner 443 may be identified by a full name, a short name and/or a unique identifier string.

FIG. 2 provides additional details of the folder management screen. The user is presented with standard screen functionality such as home, help and log off 211. The current user and user organization are presented in the header 212. This is helpful for users who may belong to more than one organization. Options for accessing additional screens, such as the in box, composing a document, searching, addressee's and folders are presented. For FIG. 2, the active option is folders. Several columns of information about folders are provided, including folder name 222, number of documents in a folder 223 and number of unread documents in the folder 224. Additional columns of information can be provided.

FIG. 3 provides additional details of the file list screen. General aspects of the screen follow the format of other screens, e.g. 211, 212, 221. The current folder being viewed and other folders available for view can be listed in the navigation box 331. The checkboxes 332 are provided for selecting individual documents to delete or to move to a folder. A column identifying the trading partners from whom documents originated 333 is provided. Date and time information and document types also are provided 334, 335. Icons for the document also can be provided 336. From the envelope icon, the user will know if the document has been read or not and also may know if it has been forwarded or replied to. From the export icon, the user can export the document. The same functionality can be provided for exporting a series of documents that have been checked. From the clip icon, the user can know if there are attachments associated with the document. The clip icon may allow direct access to a list of attachments or to the attachments themselves.

The document type selection screen of FIG. 4 can lead to either a search or a reply action, depending on the context. In FIG. 4, a trading partner name and document type may be described in the banner 441, if they have been selected. Selection of a document type provides a context for either searching or replying. FIG. 5 depicts a sample search screen that includes many of the same features as other sample screens, e.g., 211, 212, 221, and 331. One or more field selection filters 512, 513 are supplied. The values accessible by the pull down menus of these filters are context sensitive to a selected document type, if the document type is selected by a filter 518 or has been selected by context in a prior screen. Only the field types that are valid for a particular document type appear in the pull down menu, once a document type has been selected. One or more value specification fields 514 also are provided. These value specification fields are context sensitive to the document fields. The user's entry can be checked for format and data type as the user enters the data. The combination of field selection filters and value specification fields, context sensitive to the document type selected, enables a generic interface for searching across different document types. In addition to generic field handling, additional filters can be provided to search by date 515, document status 516, trading partner 517 or other field. A variety of interfaces can be used to implement these filters, such as pull down menus, radio buttons, checkboxes, or blanks to fill in. A list of folders to search in 519 can be dynamically generated, to match the list of folders in the navigation box 221, 331.

FIG. 6 is a block diagram, at a very high level, depicting flow through activities related to exchange of documents between trading partners. A trading partner 601 using a connector sends a business document to a document router 606, which routes the document to a generic document handling service 609 within a service environment 608. The generic document handling service does some processing and, assuming no fatal error, stores the document inside database 607. Later, another trading partner 602 using a browser or other software adapted to communicate with the market site 603 accesses the Web server 604 running a document access servlet 605. The trading partner reads the document and, optionally, creates a response or uses the document as a basis for creating a new document. The second trading partner can access and create generic documents using a standard Web browser or other software. The servlet retrieves the starting document from the database 607. After a response or new document is created, the document can be sent to another trading partner 601. All of the functions of the market site 603 can be hosted on a single server. In some implementations, it is desirable to have separate servers for the router 606, the services 608, the database 607 and the Web servers 604. Additional servers or families of servers may be added for load balancing, high availability and/or security reasons.

FIG. 7 is a block diagram depicting an alternative system. Interacting with the system are an entity 701 which sends a document to the system and a user 702 who interacts with the document stored by the system. The entity sends the document to a server 708 via router and communication channels that are not depicted in the figure. The document may reach the server 708 based on the addressee of the document or a combination of addressee and document type, or it may be sent directly to a location specified by the sender. For instance, a global directory may be published that identifies locations to which participants in a marketplace desire for various types of documents to be sent. The locations may be specified in the form of market participant IDs or URLs. A market participant may have multiple IDs or URLs.

A document being sent is typically a self-describing, structured document. XML documents are a common type of self-describing, structured documents. Fields within this document are self-describing, as the fields are tagged. A sample document having two different types of tagged fields is illustrated in FIG. 8. The document 800 may have one or more parts 830, 840. For instance, the document may include a MIME header and an XML body. A MIME header may be compliant with RFC 822. The header 830 includes a plurality of tagged fields 831-833. The body 840 also includes a plurality of tagged fields 841-849. Alternatively, the document may have only one part or one type of tagged fields. These tagged fields may comply with a schema, such as an xCBL schema by Commerce One or a CXML schema by Areba. A scheme is characterized by tagged fields having types and super types. Types inherit properties from the super types on which they are based. Types are defined based on their super types and having additional properties. Other standards to which tagged fields may comply include Sox by Commerce One, ECX, the 0AGI standard of Open Applications.org, the BizTalk standard by Microsoft, the Rosetta net standard by Rosetta Net.org, and EDI X12 A32.

Referring to FIG. 7, the entity which sent a document to the system 701 may be an electronic trading partner or otherwise an electronic correspondent of the entity to which user 702 belongs. The relationship of trading partners or electronic correspondence is illustrated in FIG. 9. The trading partners participate in the trading network 900. This network may be hosted by a single entity or it may be a collaboration of networks hosted by distinct entities. The trading partners may both use the same host or they may use different hosts which route messages among themselves. Two trading partners 860, 880 are illustrated. Participants on behalf of the trading partners 861, 381 may be systems or human beings. Referring again to FIG. 7, the entity 701 which sends the document to the server 708 may be either a system or a human being. Purchasing systems are examples of entities which generate self-describing, structured, tagged field documents and send them to systems.

On server 708, one or more services 711-713 may be available. One service may receive the document 711. The same or another service 712 may persistently store the incoming document, for instance in a database 707. One or more databases may be used to store data useful for electronic commerce or other document exchange. A database may include a repository of schemas 741 for standard and entity-defined business documents, a repository of JavaBeans 742, C++ structures, Pascal records or scripts useful to electronic commerce, a document map repository 743 for translation of documents from one format to another (e.g., the xCBL format to an export format) and for transformation of documents from one type to another (e.g., from a request for quotation to a quotation.) The database may further include a report layout repository 744 and a presentation layout repository 745. The presentation layout repository may include declarative transformations for changing documents from a Sox document format to an HTML format, and back again. The transmission properties data describes the transport information needed to sent a business document to a recipient. For example, SSL security credentials can be stored as transmission properties. A trading partner directory is also useful. The trading partner directory may, as described above, identify URLs to which the sending entity 701 transmits documents. The persistent storage for data 707, 741-47 may be on a single data storage unit or multiple units. Persistent document storage need not be part of a database. An indexed flat file would suffice to store XML-compliant documents. The services host 708 may also host an indexing service to index one or more of the tagged fields. Alternatively, a database system managing the persistent storage or other subsystem may index documents for retrieval. An incoming document may or may not be validated against schema from a schema repository 741, before it is persistently stored. A schema may be used to interpret the document. One or more JavaBeans or Scripps may be used to act on the document before it is stored.

One schema for persistently stored documents is illustrated in FIG. 10. In this schema, a document and its header are captured in structure 1020. If this document is a copy or a reply based on an original document, the original document is stored in structure 1023. A copy or a reply document is associated with a special folder 1024. Document attachments are captured in structure 1040. Sets of valid document types and document statuses are maintained in structures 1010 and 1030, respectively. The one-to-many connections between structures 1010, 1030 and structure 1020 indicate that only one document type and one document status are allowed per document. To support searching, searchable fields are listed in a data structure 1012, and may be assigned unique or non-unique alias names. Information regarding searchable fields is listed in a separate data structure 1022. Other data arrangements may equally well practice aspects of the present invention.

Persistent storage of the incoming document may be accompanied by various processing steps. The original document, prior to normalizing, may be stored in a database. Envelope properties may be extracted from the envelope and normalized in a database or other storage. A predefined list of indexed fields, by document type, may be consulted and those fields indexed. Generic document properties, such as date and status, may be extracted from the envelope. The envelope itself may be separately stored. Attachments may be separately stored. Unneeded white space may be removed and name space abbreviations used to reduce storage requirements.

Returning to FIG. 7, the service 713 may advise the user 702 of receipt of the document by messaging, posting any other practical means. One or more users may be given notice, based on the identity of the sending entity, the identity of the receiving entity, the document type or other characteristics of the document. One syntax for subscription by a user is subscription sender ID.recipient ID.document type. To receive all Order documents from a particular sending entity, a user could subscribe as follows: subscription=S1234.*.Order. This subscription would cause service 713 to notify user 702 of receipt of order type documents from sending entity S1234. Security features of the system would, of course, restrict access appropriately. Notice may be given by messaging, such as e-mail or Lotus Notes messaging. A message may include a subject, such as, "five new documents received," header text generally stating that new documents have been received or that old documents remain to be viewed. The e-mail may further include body text providing the date, number and sending party's identities for documents received. The body text may further provide detail regarding individual documents received, such as the document type, sender identity and date or time of receipt. The user interface may identify the location for viewing the document, such as by a click through URL. Alternatively, notice may be given by posting at a location to which the user has access. A combination of notice formats may be used, such as posting followed by e-mail follow-up in the user does not promptly access listed documents. E-mails based on the status of accessing a document or a post notice may be sent periodically and may include increasingly strong wording or additional addresses, based on the type and/or aging of the received document.

A system 704 may be based upon a web server and a servlet container, for instance, compatible with JRun 3. A user interface application 721 may include a homepage 721, an in box 722, one or more services to read the document and/or its attachments 723, services for folder management 724, customized folders 725, searching for and listing documents. An additional service may provide access for downloading template documents 728. The web server may include Microsoft's WebServer software, a Java interpreter such as JRun 3 and a servlet container. A data storage interface may use the resources of a database. A first collection of services 720 is illustrated as being coupled with a transformation engine 730. The transformation engine may include selection logic 732 to select the style sheet for transformation purposes and transformation logic 731 which applies a style sheet to a document.

FIG. 11 depicts a further alternative environment in which aspects of the present invention can be practiced, similar to the environments depicted in FIGS. 6 and 7. A web server 1111 takes HTTP requests and makes HTTP responses. A generic document handling facility takes advantage of the web server resources through a program interface. One useful API is Sun Microsystems Java servlet. The so-called servlet technology provides a simple, consistent mechanism for providing access to web server services. A servlet written in Java can provide a component-based, platform-independent method for building Web-based applications. A single servlet application may be integrated with a variety of web-enabled application servers such as BEA WebLogic Application Server, IBM WebSphere, iPlanet Application Server others. Complementary to servlet technology is Java Server Pages (JSP) support 1114. The JSP technology is an extension of servlet technology that supports authoring of HTML and XML pages. JSP facilitates mixing dynamic content with static templates. JSP supports encapsulation of logic to generate content dynamically. The dynamic content logic can be accessed from the template page. The servlet runner 1112 resident on the web server may be JRun or a similar Java environment. Alternatively, a different program interface to the web server may be used with a different programming language. The servlet runner supports the servlet interface for access to the web server. The servlet runner supports the servlet controller 1113, invocation of JSP pages 1114, and a variety of applications 1121-26. Among these applications, the data access layer is an abstraction layer for access to the database 1151. The data access layer is present on each server or in each application environment that accesses the database 1133, 1144. XMLPres 1122 is a style sheet engine that handles extended XSLT style sheets for transformation of XML into HTML. The rule selector 1123, as described in the co-pending application, provides access to default or a customized rules and templates that match parameter such as document type and trading partner. The XML engine parses and processes XML documents. For XML, records can be parsed and processed using DOM, SAX or any other programming model. Folder management is provided 1125. Software and resources for processing browser forms with embedded pass specifications are also provided 1126, as described further below. E-mail notification 1131 may be structured with an e-mail module 1132, a data access layer 1133, and e-mail management routines. The e-mail module will utilize routines of the data access layer and the e-mail management library. Sun Microsystems provides a library of e-mail management routines complementary to its servlet technology. The overall generic document exchange service 1141 can be hosted within a services environment 1142. The generic document exchange service 1143 may include logic in resources for data access 1144, XML transformation is 1145 and XML searching and processing 1146. Data accessed and utilized by these routines may be stored in multiple databases 1151, 1152. A database of documents may be one component and market site data may be another, the market site data including a directory compliant with a lightweight directory access protocol.

FIG. 12 is a block diagram of a user interface and declarative data. This figure provides additional detail beyond the detail of FIG. 1. The initial three screens, for displaying a document 132, selecting a document type 133, and composing a reply or new document 141 are the same as in FIG. 1. FIG. 12 depicts the use of declarative data for a mapping selector 1231, for data transformation mapping 1211, and for display transformation 1212 in conjunction with the document type selection screen 133. The mapping selector 1231 provides a list of document types that can be produced from a selected starting document is accessed and incorporated in the user interface. The types of resulting documents that can be produced may depend on the marketplace, trading partner and other factors, as well as the document type of the starting document. From a starting document and selection of a document type for a resulting document, data transformation mapping 1211 is applied to generate a draft resulting document from the starting document. The transformation mapping should ensure that the resulting document is well formed, when the starting document is well formed. For XML to XML transformation, the declarative transformation mapping may take the form of an XSLT style sheet, potentially with extensions to XSLT. Other forms of declarative schema-to-schema mapping may also be used. Display transformation mapping utilizes declarative display format data 1121 to transform the underlying data for use in the user interface, for instance, to transform XML to HTML they can be viewed by a browser. Following document type selection 133, application of declarative data from a mapping selector, data transformation mapping, and display transformation mapping is used to produce a document updates screen 141. In one embodiment, application of one or more declarative transformations to the starting document produces a user interface form. The user interface form includes a plurality of path specifications for fields corresponding to the document type of the resulting document, starting values based on the starting document for at least some of the fields in the resulting document, and values to be completed for other fields in the resulting document. Field labels also may be included, either as data or along with other page formatting information. Alternatively, all of the fields may be populated and none left to be completed. Some fields may be editable and others not editable. The path specifications may conveniently be implemented as HTML hidden fields or otherwise as non-displaying fields. They can be displayed, for instance, for debugging. XPath is one convention that can be used for path specifications to nodes or fields within an XML document. An alias for an XPath path specification also may be used, in conjunction with a lookup from the alias to the full path specification. Aliases can double as field labels.

Sample excerpts of a document to display transformation 1212 for a main processing routine and display of header information with embedded path specifications follows: