Patent Application
20050091093
1. Field of the Invention
The present invention relates to business systems and infrastructures generally, and more particularly, to a system and method for creating and managing business process integration solutions.
2. Description of the Prior Art
Starting from a business process from user knowledge and existing documentation and creating an optimized IT solution that operates and manages the process is presently a very expensive, time-consuming undertaking. Currently, business process modeling has limited usefulness, i.e., it is largely documented in text documents including freehand diagrams etc. and lacks formal semantics. Results thus comprise unstructured solution knowledge sharable only at the code level. Furthermore, completed solution cannot be easily or automatically reconciled with the original process model and business process performance is difficult to measure and use to reengineer the process.
Known solutions to this problem currently are not cost-efficient nor time-efficient and, moreover, do not span the entire end-to-end business process. For example, Holosofx is a popular tool for creating business process models and workflows, but cannot be used to generate other necessary components, such as application adapters or business objects. Crossworlds InterChange Server is a tool for implementing business objects and business logic operations, but does not perform business process modeling or workflow generation and processing.
It would thus be highly desirable to provide a system and method for business process integration and management solutions.
Furthermore, it would be highly desirable to provide a business level modeling language that formally describes functional business models from a variety of perspectives including a strategic operational and execution point of view that serves as a basis for implementation as an Information Technology (IT) execution model, and further, facilitates business process re-engineering according to changing business goals and objectives over its development lifetime.
It is an object of the present invention to provide a cost-saving and time-saving solution for providing a business process integration and management solutions, particularly novel procedures from which an IT solution for a business process may be created.
According to the preferred embodiment of the invention, there is provided a complete system and methodology for creating business integration and management solutions. A point of novelty of the invention is its formal definition of the modeled business activities and output of each step in the solution creation process. In each step, one or more documents or other artifacts are created in accordance with well-defined schemas and specifications. Key steps are automated by algorithms in software, or assisted by tooling with graphical user interfaces. The schemas and specifications enforced the validity of the work products and guarantee compatibility with other components and the overall model. Another critical element is the incorporation of key performance indicators in the very early stages, followed through with implementation of software probes to collect the business process performance data. Once the solution is deployed, these data are reported to the business analyst for performance tuning and business process re-engineering.
In the achievement of these objects, a comprehensive methodology and tool set is provided for the complete lifecycle of a business process solution spanning: 1) business strategy modeling at the strategy level; 2) business process modeling at the operational level and, defining in the operational model, the business process measurements in terms of commitments and key performance indicators; 3) and transforming of the process model to an information technology (IT) solution composed of solution artifacts of pre-defined types including: Business Objects, Adaptive Business Objects, Macroflows, Microflows, EAI Adapters, B2B Connectors, User Interaction Screenflows; 4) simulation of the models to perform static and dynamic analysis; 5) mapping of the key performance indicators to rr probes in the rr solution; 6) defining details of the IT solution artifacts in an integrated set of graphical tools; 7) binding and deploying the solution artifacts to platform-specific runtimes; 8) Monitoring and reporting business process performance as measured by the key performance indicators being serviced by event data from probes; and 9) optional invocation of agents to recommend and/or effect changes to the business process that improve its performance.
The objects, features and advantages of the present invention will become apparent to one skilled in the art, in view of the following detailed description taken in combination with the attached drawings, in which:
This invention defines a procedure by which an IT solution for a business process can be created. In each step a specific set of artifacts are created for possible use in future steps, or for later re-use during creation of additional solutions.
As shown in
With these mappings, transformations, and connections in place, raw events, transactions 23, and environmental data can be captured and aggregated into business metrics, e.g., return on investment (ROI) or Earnings per share (EPS), for comparison with business commitments and objectives in a Business Activity Monitoring (BAM) dashboard, for example. Through a number of feedback loops 25a-25c, Continual Optimization/Sense and Respond (CO/SaR) technologies may then provide decision support to manage operational exceptions and proactively suggest process changes to optimally achieve business objectives. Finally, changes in business direction can now be directly propagated from the strategy model down to the IT infrastructure mostly by manipulating models rather than code—requiring far less time and cost than traditional business transformation engagements. This allows the business to adapt as quickly and easily as adapting the models.
More specifically, the Transformation wizard 150 may automatically transform the business level model to an IT level model (ILM) 250. The Transformation Wizard may be automated by one or more alternative algorithms that use different approaches to generating an IT architecture for the solution. The algorithms identify the necessary components that will be used in the ILM 250 including, but not limited to components, such as: business objects 201, adaptive entities (adaptive business objects) 202, screenflows 203, macroflows and workflows 204, microflows (automatically executable tasks) 205, and application or business-to-business adapters 206. An adaptive entity is a prescription for the various states that a business object can have an d transitions that a business object can undergo. A workflow is a sequence of activities, some of which involve human interaction. An application adapter is software that allows an independent application to be integrated with the process. A business-to-business adapter is software that enables an external business partner to be integrated with the process.
Further steps 115 are performed by the IT developers 51 who implement runtime development tools 185 such as IT Level Editor or “Binding Wizard” tool (not shown) that may be used for viewing or modifying the artifacts at this level. Typically, one or more IT Level Artifact Editors are employed to further specify the details of each component. This is necessary because it is not realistic for the business level model to contain sufficient detail to fully define all components at the IT level. Separately, adapters for the existing applications and business partners are either retrieved (if they had been created previously) or created. They are retrieved from the Asset Repository 400, and used by a “Binding Wizard” tool, along with the artifacts in the ILM to generate the bindings between components, which are then stored in the asset repository 400. The binding wizard particularly uses the adapter defined and the commands in the ILM repository to create concrete bindings.
A further runtime development tool is a Package Generator creates a deployable solution, e.g., files, and deploys them on local or remote machines. That is, based on the selected software and hardware platforms and topology, platform-specific components are created and the entire solution is packaged and stored in a runtime artifacts repository 500. This package is then ready for testing and deployment in a customer's environment.
As described hereinabove the Business Process Model is described according to a Business Operational Specification (BOpS) which is a business level modeling language. Business level models provide a formal representation of a business's operations, reflecting procedures and business policies, customer requirements, constraints, and a solution context. Business Analysts and Line of Business users will define such models.
Business level models can be used stand-alone, independent of any IT implementation: for cost analysis, process simulation, resource allocation or optimization studies. One of the intended purposes of a BOpS model is to serve as the basis for this class of stand-alone applications. In addition, a BOpS model is intended to be used as a starting point, and top-level “bracket” for IT implementations: as a starting point, because additional tools and procedures will be provided that will help refine the model to the level of executable solutions; and, as a top-level bracket, because the BOpS model will remain interlocked with the deployed solution, and serve as the basis for business activity monitoring, process analysis based on real-time data, and process re-engineering.
Other extensions of a BOpS model may cover enterprise models for: resource allocation and deployment, accounting and charging, asset management, security, directories and organizational structure, enterprise information models, internal and external communication channels, etc. It is expected that a BOpS model serve as a common core and starting point for virtually every aspect of modeling an enterprise.
A BOpS model is a formal representation of the business owner's view. A second way of positioning BOpS is with respect to the solution development life cycle: It is the first formal representation of a solution, succeeding the initial opportunity assessment and requirements gathering, strategy formulation and preceding any IT architecture definition.
Yet another way of positioning BOpS is with respect to the granularity of modeling a solution: It is the most fine-grained representation that business-level users win recognize. From a business user's point of view, BOpS tasks, resources, and artifacts are “atomic”. (One may tear an invoice in pieces, or disassemble a computer, but the results will no longer be recognized as “business documents” or “system resources”).
There are three views of a business system. The operational view that projects what the business does, the strategy view that describes why it does that, and the execution view that depicts how it does that. Most of the work on business process modeling focuses on the execution layer. BOpS is built on the idea that the best way to present the operational view of a business is to focus on the artifacts that the business operates on and the business elements that impact the lifecycle of those artifacts. These business elements fall into three categories: business tasks that represent irreducible business functions performed in the context of those artifacts, artifact repositories that serve as the storage for these artifacts, and the business processes that define a topology on an aggregation of business elements. The business model described by BOpS is further decomposed into three sub models. The information model captures the business artifacts and business events. The functional model captures business processes, business tasks, and the artifact repositories. The resource model captures the roles and resource groups.
It is very natural to find that modeling business operations involves modeling these three fundamental constituents of a statement: Subjects (actors), verbs (actions), and objects (artifacts). Correspondingly, as shown in
As further shown in
An overview of the syntax of BopS is now described with details of each language construct described in greater detail herein. At the highest level, BOpS uses the Business Model construct to define the operational view of a business. Included in the business model are the Information Model, Functional Model, and the Resource Model. This specification uses an informal syntax to describe the XML grammar of the XML fragments below: The syntax appears as an XML instance, but the values indicate the data types instead of values; Grammar in bold has not been introduced earlier, or is of particular interest in an example; the <--description--> is a placeholder for elements from some “other” namespace (like ##other in XSD); characters are appended to elements, attributes, and <!--descriptions--> as follows: “?” (0 or 1), “*” (0 or more), “+” (1 or more). The characters “[” and “]” are used to indicate that contained items are to be treated as a group with respect to the “?”, “*”, or “+” characters; elements and attributes separated by “|” and grouped by “(” and “)” are meant to be syntactic alternatives; the XML namespace prefixes (defined below) are used to indicate the namespace of the element being defined; examples starting with <?xm1 contain enough information to conform to this specification; others examples are fragments and require additional information to be specified in order to conform; XSD schema is provided as a formal definition of grammar. The syntactic structure of the root businessModel is now described with the basic structure of the language as follows:
According to the basic structure shown, the top-level attributes are as follows: “name” which attribute defines the name of the model; “targetNamespace” which attribute defines the targetNamespace of the document; “expressionlanguage” which attribute specifies the expression language used in the process. A current default for this attribute is XPath 1.0, represented by the URI of the XPath 1.0 specification, e.g., at http://www.w3.org/TR/1999/REC-xpath-19991116; the “informationModel”describes the above-mentioned artifacts and business events pertaining to the operational view of the business; the “functionModel” describes the above-mentioned process, task, artifact repositories and their interconnections using ports and links; the “resource Model” describes the above-mentioned organizational roles and the resource groups relevant to the business operations; and the “constraints” describes the constraints that ensure semantic validity of a BOpS business model.
Functional Model
As mentioned, the token “businesselement” can be any of the following: businessProcess; businessTask; and artifactRepository. The <businessProcess> construct describes the business process with the basic structure of the language as follows:
The <businessTask> construct describes the business task as follows:
The <artifactRepository> construct describes the artifact repository as follows:
The token “ports” referred to above is described s follows:
Information Model
The token “informationmodel” referred to above is described as follows:
Resource Model
The token “roles” referred to above is described as follows:
The token “resourceGroup” referred to above is described as follows:
The token “tAtomicResource” referred to above is described as follows:
Constraints
The constraints are described using Boolean Xpath expressions and must evaluate to true for the model to be semantically valid. The token “tConstraints” referred to above is described as follows:
BOpS business models capture the lifecycle of the key artifacts of the business operation and the business events that impact the lifecycle. Business logic at the operational level is captured using business predicates. Business artifacts, business events, and the business predicates are the underpinnings of the BOpS information model.
BOpS business models capture the lifecycle of the key artifacts of the business operation and the business events that impact the lifecycle. Business logic at the operational level is captured using business predicates. Business artifacts, business events, and the business predicates are the underpinnings of the BOpS information model.
Business Artifacts
The use of BOpS in defining the operational view of this example business and a description of the businesss' core constructs is also provided. In an example travel agent business, a travel reservation process identifies the required flight legs and hotel reservations for a customer' planned trip. It then spawns sub-processes responsible for reserving the flights and hotels. If all reservations are confirmed within a pre-defined time limit, an itinerary is printed and sent to the customer.
As mentioned, the BOpS captures the lifecycle of a business artifact as a flow of an artifact type through the business elements. The cardinality attribute of the artifact type indicates any limits on the instances of a certain artifact type. The artifact type also identifies the information variables for that artifact type. An artifact is either worked on by a Business Task or resides in an Artifact Repository. An artifact has the following attributes: name: ncname—specifies the name of the artifact; and, type: qname—specifies the type of the artifact. It is a qualified name so it could be in another namespace. An artifact is described by its type attribute that is a qualified name (referring to a namespace). The syntactic structure of an example artifact is as follows:
Business Events
Business events (for example, a fax or a phone call from a customer) may carry artifact references or copies of artifact content. Thus, a business event has the following attributes: name e.g., “ncname” specifying the name of the artifact; and, type, e.g., “qname” specifying the type of the artifact. It is a qualified name so it could be in another namespace. A business event is described by its type attribute that is a qualified name (referring to a namespace). The syntactic structure of a business event is as follows:
Business Predicates
A business predicate is an expression of conditional logic in terms of the information variables and/or artifact attributes in the model. A business predicate can be used in the following sections in the BOpS model: a Port—as a boolean expression whose evaluation decides if the artifact flows through the port; a ContextVariable—as a regular expression whose evaluation sets the value on the variable; and Constraint(s)—as a boolean expression whose evaluation validates the model. A predicate is expressed using XPath. It has the following attributes: name: ncname—a unique name for the predicate; and, expression: string: an XPath expression expressed in terms of an artifact, business event or context variable. The syntactic structure of a predicate is as follows:
As mentioned, the Business Function Model includes BusinessElements and their connections. A Business Element is a general construct in the functional model, i.e., it is manifested as a Business Process, Business Task or as an Artifact Repository. The Business Function Model is built on the core concept of business artifacts (e.g. purchase orders, customer records, contracts, invoices). It is noted that the structure of business artifacts and business events is described using the constructs of the Information Model, while their life cycle is described by the Operations Model; and business events (e.g. timer signals, alerts, notifications) being exchanged amongst business tasks. Business tasks have ports through which artifacts and events enter or exit. The ports are connected via links. Furthermore, the model features artifact repositories, which is where business artifacts reside when they are not processed in a task, and business processes which aggregate tasks, artifact repositories, and potentially nested processes, into larger operational units. It is noted that a fundamental difference between the Business Function Model and many of the existing “flow models” is that in BOpS, there are no flows. There are only tasks, which are spawned by an arriving artifact or event, perform some work, and finally send out events and artifacts which may spawn other tasks in turn. This creates a “web of interacting tasks” connected through the exchange of artifacts and events. One could follow the path of a particular artifact and define the sequence of tasks thus encountered as a “process” or “flow”. However, with this approach a given BOpS model may be dissected into flows in many ways, and for tasks operating on multiple artifacts, it may not even be clear to which flow or process they belong. While a “business process” construct in BOpS is available, this should really be thought of as a “composite task”, since from the outside, it looks and behaves exactly like a task, with ports to send or receive artifacts and events. The only difference is that for processes, their internal, operational structures are further decomposed within BOpS, while elementary tasks are not. The roles are defined in the Resource Model and referred to from the BusinessModel. A role identifies who can perform a business function.
Business Element
A business element is an abstract construct. BusinessProcess, BusinessTask and ArtifactRepository all extend BusinessElement. The syntactic structure of a business element is as follows:
Ports define the interface of a business element. A port has the following attributes:
The syntactic structure 6f a port is as follows:
Business Process
A Business Process is an aggregation of business elements, i.e., business tasks, artifact repositories, and other business processes to support hierarchical structures. A process has the following attributes—
The business model must contain at least one business process. The business process consists of business elements (process, task, artifactrepository), ports, links, and roles. Ports specify the interface of the business process. Roles specify who have the authority to perform the business function represented by the business process. Links connect ports of the business elements contained in the business process to specify the flow of artifacts through the business elements. A link has the following attributes:
The syntactic structure of a link is—
The syntactic structure of a business process is:
Business Task
A Business Task is an irreducible functional business element in the business model. Business Tasks work on artifacts. A task has the following attributes:
A business task consists of ports, taskcontext, roles, and trigger. A business task should have at least one port, while the taskcontext, roles, and trigger are optional. The role is used to identify who has the authority to perform a business task.
The syntactic structure of a business task is:
Task Context
One or more “contextVariables” may be defined for a task. A task context defines task-specific information. Potential uses of such information is to: Define variables that can be used within Boolean expressions (expressed as predicates) in a port, whose evaluation decides whether a port is active. Assign a value to a scope variable. The resource assignment of a task depends on the correct assignment of the scope variable.
The syntactic structure of a taskcontext is:
Trigger
Tasks are functional units that start processing when triggered and are guaranteed to stop after some reasonable time. A task is triggered according to the following: when an artifact enters via an ‘in’ port; when an artifact is available in a repository (in which case the call-back mechanism triggers the task via an ‘out-in’ port); by a timer; or by itself.
The syntactic structure of a trigger is:
Business Artifact Repository
An Artifact repository is the “staging area” for business artifacts. An instance of an Artifact Repository can only hold artifacts of a particular type. Artifact repository is used to model temporal dependency with ordering constraints in the business model. An artifact repository has the following attribute: name: ncname—that specifies the name of the artifact repository. Ports define the interface of an artifact repository. Since an artifact repository can hold only one type of artifact, all the ports must reference the same artifact type. The valid port directions are: ‘in’, ‘out’, and ‘in-out’.
The syntactic structure of an artifact repository is:
Resource Model
The Resource Model describes the actors performing business tasks, as well as their capabilities. A set of capabilities to perform business tasks defines a role. Actors are modeled as resources, and resources qualify for a role, if they are capable of executing the corresponding tasks. They may then be assigned to these task for execution, if they are available, and not restrained by scope considerations (see below). Note that “performing” and “assisting” resources at this level of the model is not differentiated. The boundary between the two is blurred, and usually resources participating in task execution will be occupied, consumed, or charged for, regardless of whether they are “performing” or “assisting”. Even if a resource is capable of performing a business function (i.e., it qualifies for the corresponding role), there may be limitations on its capability to perform a task that depend on the task instance. For example, several people in a company may have an “approver” role for purchase orders, but depending on the type and value of products ordered, not every one may qualify to approve every order. The concept of scope is introduced to model such instance-dependent restrictions of resource capabilities.
Resources
Resources can be human or automated (machine or system resource). In addition, an external resource type is introduced to model resources that may be beyond control of, unknown to, or irrelevant for, the process owner (opaque resource). It is understood that while the three types of resources (human, system, external) appear identical at this level of the model, differences become apparent in extensions and refinements, such as for process simulation or IT implementation. For example, human resources may eventually be mapped to entries in a corporate directory. System resources will be implemented by applications, machines, or automated tools, and may require connectors or adapters to participate in automated process execution. External resources will be different from the other two types in throughput simulations (the quantity and availability of the resource may be unknown, or unlimited), cost calculations (their cost is incurred by a third party), and IT implementations (their interactions require a B2B gateway). Resources are characterized by cost and availability, and should be thought of as “tangible” process actors having a distinguished identity (for example: Accountant Bill Smith, SAP System 4224, Airline reservation service www.flyright.com). Resources are not to be confounded with roles, which designate mere capabilities (for example: manufacturing specialist, travel agent, lead buyer, expense account approver). The same role can be taken on by resources with very different cost characteristics: for example, depending on who approves an expense account, the cost per hour in performing this task may vary greatly. As will be discussed in greater detail hereinbelow.
As an example, a human resource may be an employee in the accounting department, or a team of four IT specialists. An example for a system resource is an SAP R/3 system. An example for an external resource is an airline reservation service.
Resources may be aggregated. Aggregations of human resources, system resources, or external resources define a new (compound) resource of the same type. Aggregations of resources having different types creates a new “un-typed” resource. Combining un-typed resources with any resource will again create an un-typed resource. For example: Aggregations of human resources may be thought of as “teams” or “work groups”. Defining aggregations of system resources, as well as “mixed bags” of human and system resources, may be useful when these are usually deployed in combination. For example, an accounting process may require a resource consisting of a member of the accounting department and the corporate accounting system; a rescue operation may require a helicopter, a pilot, and a physician.
Furthermore, resource aggregations may be nested, and three basic aggregation types are allowed: a bag (unordered set); a sequence (ordered set); and a choice (alternatives). If no aggregation type is specified, a bag is the default. When assigning compound resources, the assignment of a bag will bind all resources it contains to the task. The assignment of a choice indicates that one of the resources in this set will be assigned; its selection is subject to availability, scope, or other runtime constraints, but no ranking or preference for picking a particular resource is indicated in the resource model. The semantics of assigning a sequence are similar to assigning a choice (one resource will be picked), but the sequence pre-defines some preference or priority in making this selection. An example for a resource bag is a work group; an example for a sequence is a list of shipment services ranked by cost or speed; an example for a choice is a set of corporate chauffeurs.
Finally, resources may be owned by organizations, which may be internal (e.g., departments, divisions) or external to the enterprise (e.g., business partners, external service providers). Modeling these organizations, their hierarchical structures, and their ownership of resources, however, is outside the realm of the core model. Such capabilities may be added in a model extension, for example, for process simulation.
Role
The functional capabilities of resources are described by assigning them roles, which are defined as aggregations of capabilities to perform business tasks. In IT implementations of business processes, roles are frequently used to denote authorizations or permissions to perform business functions. In an enterprise security model based on BOpS, the role concept introduced herein may be extended in this way. The assignment of a role to a resource may be scoped, in which case the resource's capability to perform the role is not universally granted for all task instances, but depends on the task at hand. As an example, a car manufacturer defines a corporate lead buyer role for procurement agents. A lead buyer's job is to ensure that purchasing contracts for production material are in line with the corporate procurement strategy. In a corporate procurement process this role may aggregate the capabilities to “approve blanket orders”, “change supplier ratings”, and “set supplier volume limits”. However, whether an employee having the lead buyer role may actually perform these tasks depends on the class of material purchased (its so-called commodity type) as well as the geographic location of the supplier. Thus, the lead buyer role is “scoped” by supplier location and commodity type. Examples for such scoped lead buyer roles would be: “lead buyer for tires purchased from U.S. based suppliers”, “lead buyer for any class of material purchased from German suppliers”, or “worldwide lead buyer for shock absorbers”.
Scopes are modeled in BOpS as name-value pairs assigned to a resource's roles. They “down-scope” the role for the resource. The scope name defines a domain for the scope (examples are: commodity type, supplier location, sales region, customer status) and the scope value the restriction of the scope within that domain (for example: commodity type=64, supplier location=Germany, sales region=EMEA, customer status=Gold, . . . ). Down-scoping the roles assigned to resources—referred to as resource qualifications—implicitly requires that a “scoping algorithm” be defined for each task requiring such a scope restricted role: it must map each instance of the task into the various scope domains defined for the roles it requires.
In the above example, the car manufacturer's procurement process includes a contract approval task to be performed by a lead buyer. This task has an associated scoping algorithm, which determines the applicable commodity type and supplier location for each contract. This will involve parsing the contract and looking up the commodity type for each line item of production material ordered. It may also involve looking up a supplier's geographic location in a supplier database.
If several scopes are assigned from the same domain, then the resulting scope is their union. After forming the union of scopes by domain, the total scope is defined as the Cartesian product across domains. Thus, for example, a sales agent whose scope is defined as (sales region=Germany, sales region=Austria, sales region=Switzerland) is responsible for the three German-speaking countries (union of the three scopes). A lead buyer whose scope is defined as (commodity type=light bulbs, commodity type=wiper blades, supplier location=Texas, supplier location=Arizona, supplier location=New Mexico) is responsible for purchases of light bulbs and wiper blades from suppliers located in these three states (Cartesian product of unions).
Frequently, scopes have a hierarchical structure. Examples include geographic locations (states within countries within geographic regions), corporate units (departments within divisions within corporate groups), or categories of products. Defining a scope as a node in such a structure is equivalent to defining it as the set of all subordinate leaves. Thus, for example, an electronics manufacturer defines a sales director role whereby a sales director is responsible for a geographic area. The company's sales areas are hierarchically structured, with geographic (NorthAmerica, LatinAmerica, EMEA, AsiaPacific) at the top level, individual countries at the next level, and states or provinces within countries at the lowest level.
In order to document the hierarchical structure of a scope domain, or to enumerate all possible scope values, one may declare the set of permitted scope values as part of the role definition. If such a “scopes”declaration is present, it is understood that the scope restrictions for resource qualifications must be a subset of the scopes thus declared. As an example, an airline company defines a customer service representative role which is scoped by customer status. The role definition for customer service representative lists Silver, Gold, and Platinum as the three possible scope values for customer status. Declaring a customer service representative with customer status=None or customer status=All would thus be an error. If no scope values had been declared under the customer service representative role, then any value for customer status would have been permissible. Also shown in the following XML example is the sales director role introduced above, scoped by geographic area. The role declaration includes the hierarchical structure of the company's sales regions.
Constraint Model
The constraint model describes the constraints that must be satisfied for a BOpS model to be semantically valid. It reflects the operational semantics of the model. Constraints may be of 2 types: 1) Metadata Constraints—which are semantic constraints that need to be specified over and above the schema constraints. These are schema level constraints (but were unable to be specified by the schema) and will usually pertain to all Instance documents; and 2) Model Constraints—which are semantic constraints specific to an Instance document. These constraints reflect the business rules/logic that need to be evaluated in order to validate the model.
While the invention has been particularly shown and described with respect to illustrative and preformed embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention which should be limited only by the scope of the appended claims.
This application relates to and wholly incorporates the subject matter of commonly owned co-pending U.S. patent application No. ______ (U.S. Attorney Docket No. YOR920030143US1 (16596)), filed Jun. 5, 2003, the whole contents and disclosure of which is incorporated by reference as if fully set forth herein.
