JP2003530628A - System and method for deploying a schema in an e-commerce network - Google Patents

Abstract

SUMMARY A method and computer system for performing a commercial transaction by exchanging electronic documents is disclosed. The computer system includes a transaction service network, which includes a plurality of transaction servers that provide services to support commercial transactions. The trading parties operate servers to communicate with the transaction service network via the Internet. Electronic documents are exchanged between trading parties participating in the transaction. Documents are written in a markup language such as XML. Tags used for document instances are defined in the schema. Each schema defines a document format corresponding to the format of the transaction. An improved XML schema that supports integrity constraints and polymorphism can be used. Schemas are identified by the use of uniform resource names. An XML processor residing on the transaction server or the trading party's server parses the document instance by looking up the URN corresponding to the schema used to interpret the document. The URN is converted to a location-dependent URI to search the schema. The URN is analyzed into a location-dependent URI by using the LDAP protocol. The URN may be converted to an LDAP URL, which may be used to search for an LDAP compatible directory. These directories serve as registries for URI values corresponding to URNs.

Description

Detailed Description of the Invention

[0001]

【Technical field】

The present invention relates to exchanging electronic documents in the electronic marketplace. More specifically,
The present invention relates to a method for extending the schema used to interpret electronic documents used in company-to-company transactions.

[0002]

[Background technology]

Technologies exist to support the exchange of electronic data between trading parties. An important and commonly used standard is the Electronic Data Interchange, commonly referred to as EDI by its acronym. This EDI refers to the set of messages used for company-to-company communication. This message is compiled into business documents that are exchanged to facilitate transactions between trading parties. Each organization that uses EDI typically stores its data in a private format. Therefore, trading parties using EDI typically need to make upfront contracts and develop software programs to map between their private data sets. Each time a new trading party is added to the client list, a new conversion program is needed to format their data to match the other trading parties on the list.

EDI solutions for supporting commercial communication standards include integrating all universally required features into global standards. EDI effectively includes a message standard for each transaction that occurs between each set of trading parties.
The inefficiencies that result from this system include the effort expended to generate a translator for each pair of trading parties and the redundancy inherent in generating the original document to facilitate almost similar transactions. Sex and is included.

Techniques also exist for facilitating secure deployment of code distributed across computer networks. Such techniques are, for example, CORBA, DCOM
And a communication system for distributed objects such as SOAP. These systems allow communication and collaboration between objects distributed over a network. Thus, they support object-oriented facilities such as inheritance and polymorphism, which allow objects to be modified safely and efficiently. However, these systems provide interfaces between objects implemented in a programming language rather than a schema language for encoding electronic documents distributed across computer networks.

Therefore, it is desired to establish an effective communication standard for encoding an electronic document. The standard must allow document formats to be evolved to facilitate new transactions, while preserving the integrity of existing document formats and the transactions they support. Since the document format library used for such standards is shared by all trading parties in the market, these resources must be available throughout the market.

[0006]

DISCLOSURE OF THE INVENTION

The present invention enables the formation of an electronic marketplace by facilitating the exchange of electronic documents between trading parties. Embodiments of the present invention provide electronic documents that enable a trading party to (1) construct a document that reflects the particular constraints of the transaction, and (2) make such a document readily available throughout the market. Including communication standards for. The communication standards used in the present invention optimize the efficiency of electronic document formation and retrieval, and thus of each transaction.

In an embodiment of the invention, commercial transactions between trading parties take place over a computer network called a transaction service network. This transaction service network is operated by market makers interested in supporting the electronic market, and the network is
Provide services that facilitate commercial transactions. Transactions are made by exchanging electronic documents between trading parties. Transaction service networks facilitate transactions such as matching trading parties to perform some form of transaction, routing documents between trading parties, providing information about the trading parties, and establishing protocols to govern the transactions. To provide services for. The trading parties access the transaction service network through a private server connected to the transaction service network via the Internet.

In an embodiment of the invention, documents supporting transactions are written in a modified form of the extensible markup language XML. The XML standard is a markup language that allows the author of a document to define the elements or "tags" used to represent an instance of the document. The ability to define tags used in a document gives the author of the document the ability to carry the semantic content of an instance of a document by using tags embedded within the instance of the document, which is a feature of the early generations. Was not available in the markup language of.

XML document instances are interpreted by using the schema referenced in the document instance, which defines a collection of tags used to encode the document instance. When using a schema to interpret a large number of document instances, the schema classifies the document format. Document formats that can be used in the present invention include purchase orders, purchase order confirmation, order status check,
Supports commercial transactions such as availability check, price check, invoice, and invoice confirmation. XML allows the author of a document to form a schema as needed to support new transactions.

Embodiments of the present invention also incorporate features of object-oriented programming in XML.
To introduce. Certain embodiments of the present invention provide a mechanism for extending a document format, allowing the document format to be explicitly defined as an extension of an existing document format. In an embodiment of the invention, the first element defined in the first schema can be extended by defining a second element in the second schema, which second element extends the definition of the first element. In some embodiments of the invention, the first element comprises a plurality of sub-elements and the expanded element comprises a plurality of sub-elements with one or more additional sub-elements. In an embodiment of the invention, the first and second schemas reside on separate servers on the transaction service network.

Embodiments of the present invention also support polymorphism. In such an embodiment,
Instance documents may be legal instances of two or more document formats. Certain embodiments of the invention support polymorphism with format extensions. In such an embodiment, the document instance of the expanding document format is also a legal instance of the expanding document format. In an embodiment of the invention, a document instance may import a first schema and a second schema, where the first schema defines a first element and the second schema is a first element. Define a second element that extends the definition. In one embodiment, the second element is referenced in the document instance of the context specified for the first element. In an embodiment of the present invention, the first schema and the second schema are on separate servers of the transaction service network.

The extension mechanism supported by the present invention enables the schema supported by a transaction service network to be securely deployed. Applications implemented to handle documents of a particular format can also handle documents of any format that is an extension of the original format. Thus, the extension mechanism allows the introduction of new document formats or the extension of existing document formats while preserving the integrity of existing applications. This feature allows document formats and applications to be deployed separately.

In an embodiment of the invention, document instances include an identifier for the schema they reference. These identifiers are persistent and position independent. Therefore, the identifier can identify the schema even if there is a change in the configuration of the underlying computer system. In one embodiment, the location identifier is a uniform resource name (URN). In an embodiment of the invention, the URN for a schema is parsed into a location dependent uniform resource identifier or URI indicating a location for the schema. These locations include HTTP sites, FTP sites or file locations. In an embodiment of the invention, URNs are analyzed into location-dependent URIs by using a registry that maps the URNs to location-dependent URIs.

In an embodiment of the present invention, a lightweight directory access protocol,
The registry for location dependent URIs is searched using version 3 (LDAPv3). This protocol provides an efficient tool for searching registries and for location dependent URIs. The URN Registry is
It is stored in a directory server compatible with LDAPv3. LDAP-compliant directory servers are x. There are 500 servers. In one embodiment, the URN
Is converted to an LDAP URL. The LDAP URL is used as a key to search the LDAP directory for location dependent URIs. In an embodiment of the invention, the directory server is the trading party's server, or X
It has access to other servers in the network that interpret ML documents.
The use of a central directory server eliminates the need for replicated repositories, which gives the URN registry scalability and consistency. In another embodiment, the registries are federated so that different nodes in the directory reside on separate servers, which gives control over a particular URN.
It can be given to the party responsible for the resource identified by the URN.

[0015]

BEST MODE FOR CARRYING OUT THE INVENTION

A. INTRODUCTION The present invention addresses the problems facing in the structure of electronic markets for company-to-company transactions. More specifically, the electronic marketplace contemplated by the present invention comprises a computer network system that facilitates transactions between trading parties, which transactions are performed by the exchange of electronic documents corresponding to a particular transaction. For example, a purchase order from a seller to a buyer is a "PurchaseOde" between the trading parties that identify the items in the transaction.
r "documents can be exchanged. The types of commercial transactions supported by the present invention include, but are not limited to, purchase orders, purchase order confirmations, order status checks, availability checks, price checks, invoices, invoice confirmations and / or catalog documents. Not something.

Various services are required to facilitate such company-to-company electronic transactions. For example, buyers and sellers must be matched to perform some form of transaction, documents must be routed between trading parties, information about the trading parties must be readily available, and a protocol in place to govern the transaction. Must. Moreover, the market system that facilitates commercial transactions must be extensible. I mean,
A system that is flexible enough to support a large number of transactions must allow for trading parties to join the market at all times.

B. Electronic Market Overview In an embodiment of the invention, these services are provided by a network of computers shown in FIG. The service providing network 100 is referred to as a transaction service network 100, which is typically operated by a "market maker", an organization that is interested in promoting the electronic marketplace. Buyer site 102 and seller site 1
04 is connected to the transaction service network 100 via the Internet. This network includes a group of transaction servers 108 that provide various commercial services. Transaction server 108
It can be added to the network as needed, providing scalability to the transaction service network 100.

Previous attempts to establish an electronic market have lacked a standard suitable for communicating between trading parties. This shortcoming results in the generation of redundant documents, which has not provided an efficient tool for constructing new transactions from old documents. Therefore, there is a need in the market to implement a communication standard that facilitates modification of existing documents and eliminates redundancy in document collection, while maintaining the flexibility to accept new transactions.

C. It is desirable to establish a communication standard for encoding transactions that take place in the XML electronic marketplace as the basis for commercial communication standards . The standard must be flexible and expressive enough to encode any possible transaction between trading parties. Also, the standard should be able to efficiently form new transactions from old transactions, thereby eliminating the need to form and interpret redundant messages in the electronic marketplace. In an embodiment of the invention, transactions are encoded in documents written in markup language. These documents are exchanged between trading parties to facilitate transactions on the market. Documents written in markup language are
Interpreted by the use of embedded tags, such languages are, for example, HTML
And SGML.

In an embodiment of the invention, the markup language used to write electronic documents is
It is an improved version of XML. Standard XML is a markup language that allows the author of a document to define the set of tags used to interpret a given document "instance". A collection of tags is defined in a file called a "schema", and each instance of an XML document is interpreted by referencing the schema referenced by the instance. The schema defines a collection of tags that can be used to interpret a large number of document instances, so the schema is
It is said to define a "document format." Correspondingly, an instance of a document format contains an XML document that cites each schema. In standard XML, a schema is defined in a document format definition file, that is, DTD. The DTD may be external or internal to each document instance.

XML document instances are checked at two levels: each document is checked for (1) conformance with XML syntax and (2) conformance with referenced schema. The distinction will be described as an example. Document format "Pu
Consider a specific purchase order document instance of "rchaseOrder". Suppose we have a document format "PurchaseOrder" and an instance of PurchaseOrder that may be referred to as PO_Instance. OP_Instance is a specific purchase order sent through the market. An OP_Instance is said to be "well formed" if it meets a set of general syntax criteria specified by standard XML. Furthermore, OP_Instance is PurchaseOd.
er is correct, OP_Instance is PurchaseOr
It is said to be "effective" for der. Effectiveness is more demanding than well-formed ones. This is because a document instance can be well formed even if it is not valid for that document type.

In an embodiment of the invention, XML document instances are parsed in an XML processor. The XMP Processor is an application that is responsible for understanding well-formed XML syntax and validating XML documents. In an embodiment of the present invention, each transaction server and each trading party site allows each server to understand the documents exchanged in the marketplace XML.
Can have a processor.

However, standard XML alone is not enough to facilitate the electronic market. Among the shortcomings of standard XML as an electronic commerce protocol, language is
It may not provide sufficient means for checking integrity constraints on the data. Moreover, conventional XML does not support polymorphic changes to the schema. Therefore, the schema must be completely rewritten to accommodate the slight changes to conventional transactions with existing schemas. Moreover, changes to the schema have a global impact on the application that creates and processes the document instance.

In the absence of polymorphism, double efforts would be made to form an almost redundant schema. This drawback will be described as an example. Think of a transaction like a purchase order. Each individual seller in the market probably has unique constraints or extensions to its business in the purchase order, which must be reflected in any purchase order that the seller communicates to. Standard X
ML does not allow polymorphic changes to existing schemas, so in this example, each buyer must write a purchase order schema to reflect their transaction constraints. The result is a double endeavor, resulting in a number of nearly similar schemas. Therefore, the present invention includes improvements in XML that overcome these drawbacks.

D. Improved XML and Polymorphic Schema In an embodiment of the invention, a standard XML schema is extended with an improved schema language that supports polymorphic and integrity constraints in XML documents. Improved XM
A non-limiting example of the L schema language is Commerce One's SOX
Includes language and Microsoft's XDR standard.

Embodiments of the present invention support format extensions. In such an embodiment, the improved schema language allows document formats to be explicitly defined as extensions of existing document formats. Thus, the improved schema language allows for the formation of extended hierarchy of document formats. Another embodiment of the present invention is also polymorphism.
Also, an instance of document format T is therefore also a legal instance of document format T ′.

Embodiments of the present invention combine formal extensions with polymorphism. In such an embodiment, an application implemented to handle a particular format T document can handle any format document that is an extension of that format T. Thus, by combining formal extensions with polymorphism, the schema language allows runtime safe extensions of formalities. Thus, combining these features decouples document format and application deployment, which is desirable in a widely deployed transaction service network.

The use of polymorphic schemas in the electronic marketplace can be explained with reference to the example of FIG. The schema language used for this description is the SOX language, but XML
This example is equally valid for improved schema languages that support polymorphism in. A group of trading parties has a document format "PurchaseOrder"
Suppose you have agreed on a schema for. The schema corresponding to the document format is the “PurchaseOrder.sox” 200 schema. "Purc
caseOrder. sox ”200 is a CBL. Refers to tags from an existing library of SOX components in a file called sox216, with the acronym CBL meaning "Common Business Library". The “PurchaseOrder.sox” schema 200 is CBL. so
It includes an identifier 202 for x216. CBL. The sox 216 includes a tag <Address> for supporting an address. This <Address> tag includes the following as subelements. <Name><street><city><postalcode>

<Address> is used by a document instance of the form “PurchaseOrder”, and the particular trading partner ACME is “Purchas”.
eOrder. Suppose we want to make a simple extension to the <Address> element used in sox "200. More specifically, ACME is <Add
"Purchase" so that the <ress> element can contain a phone number.
Order. Hope to extend the sox "200. As will be explained below, the present invention allows such an extension of the <Address> tag, i.e. the polymorphic feature allows the extended <Address> tag to be used for instance documents of the form PurchaseOrder. PurchaseOrder. so
Allows the integrity of the x schema and existing instance documents of that type to be preserved.

The <Address> tag can be extended to form a small document format “ContactAddress” by using the SOX schema language, and the corresponding schema “ContactAddress.sox” 204 can be expanded in <Address>. CBL. Extend sox 216 to include a phone number. The extended tag or element is referred to as <Contact> and this element is the ContactAddress. defined in sox, which is
It is expressed as follows. <schema uri = "ContactAddress.sox"><namespace prefix = "CBL" uri = "CBL.sox"/><elementtype name = "Contact"><extend prefix = "CBL" type = "Address"><append><element type = "PhoneNumber" occurs = "*"/></append></extend></elementtype></schema>

The new document format “ContactAddress” is CBL. sox216
Includes identifier 206 for A document instance 208 of the format “PurchaseOrder” has a schema “ContactAddress.sox” 204
And <CBL.sox ”216 by import statements respectively to incorporate a new <Contact> tag. This <Contact> tag can be used anywhere in the document instance specified for the original <Address> tag. The benefits of polymorphism are clear from this example: the new short document format "Con
The <Address> tag was extended to form a <Contact> tag by writing "tactAddress". Therefore, the new document format "Cont
"actAddress" retains the integrity of "PurchaseOrder" while extending the functionality of the original "PurchaseOrder" document format.

Without support for polymorphism, the extension to the <Address> tag is Pur
Requires rewriting of chaseOrder. This is a basic document format that is agreed between the trading parties to the standard, on which multiple document instances and transactions are composed, changes the basic document format, and slight changes are acceptable. To do so. As a result, (1) each trading party must agree on a new PurchaseOrder and must recheck the software to ensure conformance with the new definition, or (2) Ensure that the new schema has a different name, and whenever a trading party wishes to submit a purchase order, the other party will either support the new PurchaseOrder or require conversion to an older version. There is.

To support polymorphism, the schema must have the following properties. -The schema must be available in publicly available repositories and must be dynamically retrievable by trading parties. Schema identifier 202 206 2
The 10 212 214 must have globally unique names to help their dynamic discovery and loading. -When the trading party receives the document instance, <? import. ． >
The statement lists the schema needed to parse it correctly. Therefore, the recipient must dynamically load the new schema according to the identifier 212 214 following the import statement in the document instance 208.

Therefore, the improved schema language introduces new challenges for implementing document exchange systems. One of these challenges arises from the schema evolution in such languages. To facilitate the e-commerce document exchange system, documents written before the schema change must be able to be linked as they are parsed against the changed schema. Since the revised schema exists at different physical locations in the document exchange system, the links to the schema in the document instance written before the schema change must be kept valid. Therefore, the use of polymorphic documents within a document exchange system requires a permanent, position-independent identifier for the schema.

E. Use of Modularity and Persistent Position Independent Identifiers It is also desirable that an XML entity exhibit modularity, ie the XML entity can be reused. To demonstrate that this feature is desirable, assume that there is an XML document that is a well-understood XML document schema that defines the tags used for multiple document instances. When such a schema is available, it is desirable to reuse it in multiple instances rather than rewriting it for each instance.

To reuse the schema in multiple document instances, the schema is
It should have a universal name that can be used by any document instance that references the schema. This name must also be persistent so that document instances that refer to the schema are indefinitely valid. Furthermore, so that references to the schema are kept valid even if the location of the schema changes,
It is desirable for the name to be position independent. Thus, the modularity of XML code also suggests the need for persistent position independent identifiers for XML entities.

F. Schema Identification by URN The present invention provides a solution to the above problem. In an embodiment of the invention, schemas are identified by static location independent names. In the preferred embodiment, these identifiers include a uniform resource name or URN. The uniform resource name is described in RFC2079. URN is the name for a resource that resides on a LAN, WAN or the Internet. These names are characterized by two signal features: 1) URN is static. As explained in RFC 2141, URN is
It is configured to continue indefinitely even if the configuration of the computer system in which the resource identified by the URN exists changes. This is in stark contrast to network addresses, IP addresses, or file locations, which all identify a physical location on the network and become invalid if the physical location changes. . 2) URN is position independent. Again, this is in contrast to network addresses and file locations. The system resource identified by the URN retains its URN even if the network location changes, which is the IP address, LA
At N addresses or file locations, this is not the case.

In an embodiment of the invention, each schema is identified by a URN. This is shown in FIG. Document instances 208 of the form "PurchaseOrder" are represented by the scheme "Pu" by their respective URN identifiers 210, 212, 214.
rchaseOrder. sox ”200,“ ContactAddress.
"sox" 204 and "CBL.sox" 216 are identified. Similarly, "Pur
chaseOrder. sox ”200 and“ ContactAddress.
The definition for “sox” 204 is “CB” by its URN identifiers 202, 206.
L. sox ”216.

The syntax of URN is specified in RFC2141. They are specified in the following format. <URN> :: = “urn:” <NID> ”:” <NSS> where <NID> is the namespace identifier and <NSS> is the namespace specific string. The description of URN is Purcha in the present invention.
seOrder. Given by the URN for sox200, this is expressed as: urn :: x- Commerceone: document: Com: Commerceon
e: marketsite: bussinesservices: PO. so
x $ 1.0 However, NID is x-commerceone, and NSS is document: com: commerceone: marketsite.
: Bussinesservices: PO. Sox is $ 1.0. When the XML processor reads the schema, the processor searches the URN for the schema. This requires parsing the URN against physical locations such as network locations, URLs or file locations. Therefore, embodiments of the present invention also include a method of analyzing a URN for physical locations.

G. In the embodiment of the present invention that analyzes the URN via the registry , the URN is mapped to a physical location by converting this URN into a URI or uniform resource identifier. RFC2396
The uniform resource identifier described in Section 1 identifies physical locations for computer system resources. URI is HTTP, FTP or Telnet
It can take the form of a network location such as a site or a file location within a computer system. In order to analyze the URN into physical locations, embodiments of the present invention include:
The URN is mapped to the URI and, correspondingly, the permanent position independent identifier is mapped to the actual physical position. The method used for this mapping must be extensible to facilitate the addition of new schemas and document formats to the market, and can be easily searched and searched when the network location of schemas changes frequently. Must be able to make updates. Furthermore, the mapping method is such that each server in the market with the XML processor 302, namely the buyer site 102, the seller site 1
04. The transaction server 108 must be able to access the schema to interpret the document. Therefore, the URN analysis method must also be able to access each server in the market.

Embodiments of the present invention address these issues by using a registry to map URNs to URIs. The registry resides in a directory service accessible by any site in the electronic marketplace, either by the trading party's site or by any transaction service within the transaction service network. Figure 1 illustrates this feature of the electronic market. Buyer site 102, seller site 104, and transaction service 108 all communicate with the URN registry at directory server 110. This layout provides extensibility to the system because the transaction server or the trading party's server can also communicate with the registry.

To analyze the URN by using the registry, x. An access protocol is needed to retrieve the name of the schema from the 500 directory. Embodiments of the present invention utilize a lightweight directory access protocol or LDA.
Use P. The LDAPv3 protocol is a client-server protocol for performing lookups on remote directory servers.
In the present invention, a protocol is used to allow a transaction server and a trading party to retrieve a resource location via a registry.

FIG. 3 illustrates the use of LDAP to retrieve a schema location from a directory. The entity manager 304 receives the XML document instance 300. An entity manager is an application that runs on any transaction server or trading party site, that is, it manages an XML document stream and is a URI-based resource required or referenced by an XML document system. Easy to open and track. The information collected by the entity manager 304 serves to understand the well-formed XML syntax, the XML processor 30.
Passed to 2. Upon parsing the XML document instance 300, the XML processor 302 obtains the URN for the schema from the entity manager 304.
Send to. The entity manager 304 joins the LDAP lookup service 306, which searches the directory service 308 for the URI that corresponds to the URN.

In one embodiment, the LDAP-compliant directory service 308 used to analyze the URN is an X. Includes 500 servers. In another embodiment, the directory service 308 may be another type of directory service that has similar functionality to LDAPv3. X. 500 Directory Server is RFC
2253. X. In an LDAP compatible directory service such as 500, the directory service stores the primary key as a "distinguished name" commonly referred to as "DN". The DN is composed of a string of attribute values. The format of the attributes includes: CN Common Name OU Organizational Unit Name O Organizational Name

The DN consists of a string of one or more attribute values for the above attribute types. The attribute format is organized in a tree-based hierarchy, which facilitates searching and searching for distinguished names. In the present invention, the DN defines the corresponding URI as x. Fifty
Serves as the primary key for searching the 0 directory. Before using the DN as the key to retrieve the corresponding URI for the schema,
The URN for that schema must be mapped to the DN. This step is done by using the LDAP URL. LDAP URL standard is RF2
255. This standard specifies the syntax for translating URNs into distinguished names. In the embodiment of the present invention, the entity manager 304 is responsible for converting the URN into an LDAP URL. The distinguished name is then used to search the LDAP matching directory for LDAP.
Can be used for protocols. LD through a directory search
It is executed by the AP lookup service 306.

The schema search procedure described above includes the following steps. 1) Obtain the input URN and perform a map to an LDAP URL. 2) Obtain the LDAP URL from step 1, convert it to DN, and search the LDAP directory. 3) Search the URI corresponding to the URN by searching the LDAP directory with DN. 4) Search and search the schema by using the URI. The steps of this procedure must be explained by the following non-limiting example of retrieving a schema from its URN.

H. Example: Retrieving Purchase Order Schema from its URN In this example, PurchaseOrder. The sox200 schema is XML
It must be retrieved by the processor 302. PurchaseOrder
． The URN for sox200 is specified as follows. urn :: x- Commerceone: document: Com: Commerceon
e: marketsitesite: businessservices: PO. sox
$ 1.0 This includes the following components: NI = x-commerceone NSS = document: com: commerceone: market
site: business services: PO. sox $ 1.0

In an embodiment of the invention, the namespace identifier, N, for all schemas
I is "x-commerceone". The namespace-specific string or NSS is divided into two parts, one part representing the "logical directory" and the other part representing the version of the document. These two parts of the NSS are delimited by the "$" token. Thus, the logical directory is given as: document: com: commerceeone: marketsite
: Business services: PO. sox and version are given as 1.0. A logical directory is a hierarchical name for documents bounded by a colon ":". This hierarchy corresponds to the hierarchy in the LDAP directory for the schema root in reverse order. The schema root is a distinguished name that represents the logical origin for schema entities in the directory tree. In this example, the schema root is given as: ou = schema, o = market B

The next step is to convert the above URN into its corresponding LDAP URL. The format for a standard LDAP URL is RFC2255, as described above, and is represented as: Ldapurl = schema ": // [host port] [" / "[DN ["? ”
[Attribute] ["?" [Range] ["?" [Filter] ["?" Extension]]]]]] The parameters used for mapping are "schema", "host port", and "DN". is there. The schema in this case is equal to "LDAP". The host port is given as "/". This token indicates to the entry manager 304 that the host and port will be parsed during directory lookup. The DN for a purchase order in the example shown here is as follows. cn = PO. sox, ou = n1_0 ou = businesservices ou = marksitesite ou = commerceone ou = com The remaining parameters in the LDAP definition are not used. Therefore, the LDAP URL for the purchase order should be: LDAP: /// cn = PO. sox, ou = n1_0, ou = busine
ssservices, ou = marketsite, ou = commerce
one, on = com

An example of an algorithm for performing the mapping is as follows. 1) Initialize a string variable to store the output LDAP URL. 2) Insert "LDAP: ///" into the variable. 3) From the input URN the prefix "urn: x-commerceone:
document "is removed. Triggers an exception if this prefix does not exist. 4) Parse each token in the URN delimited by ":". 5) Insert each token into the LIFO buffer. 6) The rest of the input URN is the version component. Remove the "$" delimiter and store the rest as the version string. 7) If the string is not "1.0" then the schema is not version compatible and therefore triggers an exception. 8) Remove the first token from the LIFO buffer and then "DocName"
Is stored in the string variable displayed as.

9) Form a string for DN by inserting a DocName string preceded by “cn =” and ended with “,”. 10) If the version string starts with some digits, it is prefixed with "n" and "_" is used instead of ".". In the example shown here, the version string "1.0" is mapped to "n1_0". 11) Attach the modified version string to the DN with the prefix "ou =" and end with ",". 12) For each token in the LIFO buffer, prefix the token with "ou =" and end the token with ",", and attach the modified token to the DN string. The final token in the LIFO buffer must end with a ".". 13) Insert the DN string into the LDAP URL. The result of the mapping algorithm applied to the current URN is as follows. LDAP: /// cn = PO. sox, ou = n1_0, ou = busine
ssservices, ou = marketsite, ou = commerc
eone, ou = com LDAP embedded in LDAP URL is LDAP lookup service 306
By x. Used to search 500 directories.

FIG. 4 shows a directory tree. The nodes of the tree correspond to the attributes in the DN, and the leaves contain the URIs for the various schemas. The LDAP lookup service uses a third "/" as an indication of host and port,
Take it to the schema root node 400. The DNs are now traversed in reverse order. The “ou = com” attribute is brought to the corresponding node in the LDAP tree 402. The next attribute is ou = commerceone, which is
It has a corresponding node 404. The route 406 is the DN specified in the LDAP URL.
It is clear that each attribute “ou” has a corresponding node in the route 406. The search ends at leaf node 408, which in this case is ht tp: // www. mp. com / po. Contains the desired URI, which is sox . The schema retrieval system described in this example meets previously established criteria such as persistence and position independence, and exhibits a number of advantages that are not immediately apparent. These features deserve more detail.

I. Among the criteria listed for the effects schema identifier of the present invention are persistence and position independence. URN persistence and location independence are achieved by providing a centralized URN repository that is easy to update. The registry, in an embodiment of the invention, is x.x with a directory tree as shown in FIG. There are 500 directories.
The physical location for a given resource can be updated simply by updating the corresponding leaf node. For example, the position of the purchase order schema in the above example is http: // www. marketsite. Suppose it has been changed to net / foo . This can be easily done by simply replacing the current content of the leaf node 408 with a new URL. Therefore, even if the old URL is obsolete, the URN remains constant and the corresponding URN persists. The URN is also position independent when the physical location of the resource is the new network location while the URN is kept constant. Therefore, documents referencing the schema by the URN are kept valid under the change of position.

Maintaining a centralized URN repository provides scalability, completeness and flexibility to the schema search system. Having a centralized repository eliminates the need for list duplication of schema locations. This frees the system's memory for other uses. The centralized repository also contributes to system scalability.
This is because new servers added to the system can access the schema just by accessing the URN repository. Also, the elimination of the duplicate list preserves the integrity of the schema location. This is because the system can make updates to the registry relatively easily, as described above, and the centralized nature of the repository eliminates the risk of inconsistent location information for the schema. Embodiments of the present invention also facilitate schema searching. Since the URN repository is stored in the directory tree, searching network locations is faster by a logarithmic factor than flat file repositories.

Furthermore, the object-oriented features supported by the improved schema language of the present invention allow for secure extension and expansion of elements defined in that language.
Format extensions allow elements to be defined as extensions of existing elements. Polymorphism allows the extended element to be used in the context specified for the original element. By combining polymorphism with formal extensions, the schema language enables formal extensions of formalities at runtime. Thus, document formats and applications can be individually deployed in transaction service networks.

Thus, the extension mechanism in the schema language allows trading parties to easily modify existing document formats while maintaining the integrity of document instances and applications that depend on the original document format. The transacting party allows the existing document format to be modified or extended to accept new transactions while maintaining the integrity of applications that rely on the original document format. Thus, the improved schema language can preserve the integrity of existing applications in a transaction service network while providing flexibility in forming and modifying transactions.

J. Alternative Embodiments Another embodiment of the repository includes a federated directory service such that individual nodes of the directory service reside on separate servers. In an embodiment of the invention, the schema unique to a particular trading party is stored at the site operated by that trading party. For example, a particular buyer may modify the PurchaseOrder schema to suit their needs. In an embodiment of the invention, the nodes of the LDAP tree leading to the leaf with the URI for the modified PurchaseOrder are present at the buyer's managed site. This embodiment allows the buyer's site to update itself the nodes leading to a particular schema location without going through a central directory service. Thus, this embodiment decentralizes the process of updating directory services, while preserving directory integrity and eliminating the need for URN repository replication.

K. CONCLUSION The above description of various embodiments of the invention is merely illustrative of the invention,
The present invention is not limited to the detailed forms described above. Many modifications and equivalent arrangements will be apparent.

[Brief description of drawings]

FIG. 1 is a diagram schematically showing a network layout of an electronic market according to an embodiment of the present invention.

FIG. 2 is a diagram illustrating the use of URN to dynamically link an XML schema with a document instance in an embodiment of the invention.

FIG. 3 is a diagram showing an application that plays a role of parsing an XML document according to an embodiment of the present invention.

FIG. 4 is a diagram showing an LDAP directory tree used to analyze a URN according to an embodiment of the present invention.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72) Inventor Koistinen Yari             United States California             94306 Pal Alto El Camino             Yeah 4159-pee (72) Inventor Davidson Andrew             United States California             95006 Boulder Creek Hopkin             Sugarchi 1222 [Continued summary] N is converted to a position-dependent URI to search the schema. Will be replaced. URN uses the LDAP protocol It is analyzed into a position-dependent URI. URN to LDAP Convert it to a URL and use it to You may search the tree. These directories Is a registry for URI values corresponding to URNs and Then work.

Claims (35)

[Claims] 1. A computer network system for processing an electronic document encoded in a markup language, comprising a communication channel and a first server, the first server communicating with the communication channel, and the first server. The server stores a first schema, the first schema including a definition for a first element in a markup language, the definition of the first element further including a first subelement in the markup language. , Further comprising a second server, the second server communicating with the communication channel,
The second server stores a second schema, the second schema containing a definition for a second element in a markup language, the definition of the second element being:
Further, a computer network system including the first sub-element and a second sub-element in a markup language. 2. The communication channel is a local area network (LA).
The computer network system according to claim 1, including N). 3. The local area network further comprises an Ethernet (
The computer network system according to claim 2, including a registered trademark LAN. 4. The communication channel is a wide area network (WAN).
The computer network system according to claim 1, further comprising: 5. The computer network system according to claim 1, wherein the communication channel includes the Internet. 6. The computer network system according to claim 1, wherein the markup language includes XML. 7. A third server further comprising a third server in communication with the communication channel, the third server storing a first XML document instance, the first document instance including the first document instance. The computer network system of claim 6, which is interpreted by the use of a schema. 8. The computer network system according to claim 7, wherein the first document instance includes the first element. 9. The first document instance includes the second element,
8. The computer network system according to claim 7, wherein a second element is used at a position designated for the first element in the first document instance. 10. A fourth server further comprising a fourth server in communication with the communication channel, the fourth server storing a second XML document instance, the second document instance including the second document instance. The computer network system of claim 9, which is interpreted by the use of a schema. 11. The computer network system according to claim 10, wherein the second document instance includes the second element. 12. The computer network system according to claim 11, wherein the second element is used at a position designated for the first element in the second document instance. 13. The first document instance and the second document instance are
The computer network according to claim 10, which corresponds to a document format, and the document format is at least one of a purchase order, confirmation of purchase order, order status check, availability check, price check, invoice, and invoice confirmation. system. 14. A method for extending the definition of a first tag used in a first electronic document, wherein the electronic document is encoded in a markup language and the document is stored on a server of a computer network. , The method defines a first tag in a first schema, the definition of the first tag includes a plurality of elements from a markup language, and defines a second tag in a second schema, the second tag Includes a plurality of elements from the markup language and additional elements from the markup language to access the first schema and the second schema in the first electronic document to access the first schema.
Encoding the text in the first electronic document using the tag and the second tag. 15. The method of claim 14, parsing a first electronic document, the first electronic document being parsed by a parser for a markup language, the parser being stored on a server. 16. The method of claim 15, wherein the second tag is used at a location designated for the first tag in an electronic document. 17. The method of claim 16, wherein the markup language is XML. 18. The method according to claim 17, wherein the first document corresponds to at least one of a purchase order, confirmation of purchase order, order status check, availability check, price check, invoice and invoice confirmation. . 19. The method of claim 14, wherein the first electronic document includes a first tag and a second tag. 20. The method of claim 14, wherein the second schema is accessed in the second electronic document and the second tag is used to encode the second electronic document. 21. The method of claim 20, parsing a second document, the second electronic document being parsed by a parser for a markup language, the parser being stored on a server. 22. The method of claim 21, wherein the markup language is XML. 23. The method of claim 22, wherein the second document corresponds to a commercial transaction. 24. The method of claim 23, wherein the commercial transaction is selected from the group consisting of purchase order, purchase order confirmation, order status check, availability check, price check, invoice and invoice confirmation. 25. A computer network system for processing a document instance of a markup language, said first schema being defined by means for defining a first schema in the computer network system and using a second schema existing in the computer network system. A computer network system comprising: a means for extending the definition of the above, and a means for importing the second schema into a document instance. 26. The computer network system according to claim 25, wherein the markup language is XML. 27. The first schema definition includes a tag definition.
The computer network system described in. 28. The computer network system of claim 27, further comprising means for extending the tag definition by using a second schema. 29. The computer network system according to claim 28, wherein the document instance includes a tag. 30. The computer network system of claim 28, further comprising means for using the tag extension in the document instance, the tag extension being used at the location specified in the tag in the document instance. 31. In a computer network system comprising a plurality of servers, a method for interpreting an XML document residing on a first server of the plurality of servers comprises a second server of the plurality of servers to a first schema. Access this first
The schema defines one or more elements used in a document instance, and a second schema is accessed from a third server of the plurality of servers to access the second schema.
The schema includes modifying at least one element from one or more elements used for the document instance. 32. The method of claim 31, wherein a computer network system is used to perform a commercial transaction between two or more trading parties. 33. The method of claim 32, wherein the XML document corresponds to a commercial transaction. 34. The method of claim 33, wherein the commercial transaction is one of a purchase order, purchase order confirmation, order status check, availability check, price check, invoice and invoice confirmation. 35. The method of claim 31, parsing an XML document, the document being parsed by an XML processor residing on a fourth server of the plurality of servers.