BACKGROUND [0001] Electronic data interchange (EDI) is one of the ways businesses use for exchanging computer-to-computer business information based on approved formatting standards and schemas. For example, millions of companies around the world transmit data associated with business transactions (e.g., purchase orders, shipping/air bills, invoices, or the like) using EDI to conduct commerce. [0002] In a typical EDI transaction model, a large business entity or an EDI integration broker trades with numerous partners and has the technical capability to handle numerous EDI transaction data in various EDI formats and schemas. These entities, also known as "hubs," transact with one or more suppliers, also known as "spokes": Each of the spokes typically is a relatively small business entity that is only capable of dealing with one hub. [0003] Before the spokes attempt to initiate transactions via EDI with the hub, the hub typically transmits various EDI schemas to the spokes so that the spokes may properly format the EDI transactions according to the EDI schemas. Currently, EDI schemas are large in size and the file size for each EDI schema typically ranges from 1 MB to 3 MB. In addition, the hub or large trading partners customarily transmit a large amount of schemas to the spokes, without taking into considerations of the spokes' lack of hardware capability. As such, thousands of such schemas, which may occupy several Gigabytes in bandwidth during transmission, are transmitted from the hub to the spokes. [0004] In addition to transmitting a large amount of schemas which consume the spokes' transmission bandwidth, related systems or techniques define EDI schemas using a linear or flat file-based to represent EDI schemas. These types or models of representation, while having a simple composition, do not have the full capability to represent additional and sometimes have critical information associated with EDI schemas. As such, the spokes and the hub alike may not maximize the fill] benefit of the convenience of EDI transactions. SUMMARY [0005] Embodiments of the invention enhance the previous approaches and practices of representing EDI schemas by describing a structured EDI documents using extensible Markup Language (XML) configurations. By modeling an EDI payload as XML payload during runtime, embodiments of the invention reduce the time in developing schemas and transformation maps. In addition, alternative embodiments generate annotations in the XML EDI schemas including information associated with a plurality of validation rules that exists in the EDI data. [0006] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [0007] Other features will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS [0008] FIG. I is a block diagram illustrating a system for conducting electronic data interchange (EDI) transactions according to an embodiment of the invention. [0009] FIG. 2 is a block diagram illustrating a structured EDI schema using XML according to an embodiment of the invention. [0010] FIG. 3 is a diagram illustrating a XML schema embodying aspects of the invention. [0011] FIG. 4 is a block diagram illustrating an exemplary computer-readable medium on which aspects of the invention may be stored. [0012] FIG. 5 is an exemplary flow chart illustrating operations of modeling an EDI document using extensible Markup Language (XML) at runtime. [0013] FIG; 6 is a block diagram illustrating one example of a suitable computing system environment in which the invention may be implemented. [0014] Corresponding reference characters indicate corresponding parts throughout the drawings. DETAILED DESCRIPTION [0015] Referring first to FIG. 1, a block diagram illustrates a system 100 for conducting electronic data interchange (EDI) transactions according to an embodiment of the invention. The system 100 includes a hub 102 linked to and communicating with one or more spokes 104. In one embodiment, the hub 102 includes a server computer or a computing device serving one or more processors (e.g., processor 106) or processing units for executing computer-executable instructions for serving the spokes 104. In one example, the spokes 104 include a computing device having one or more components included in or coupled with a computer 130, as shown in FIG. 6. [0016] In one example, the hub 102 also includes a memory area 108 for storing one or more EDI schemas, such as an EDI schema 110. Initially, the hub 102 and the spokes 104 establish agreements as to the EDI formats or standards to be used for transmitting transaction data therebetween. Once the parties determine the particular EDI formats or standards to use, the hub 102 selects the appropriate EDI schemas to be transmitted to the spokes 104. In another example, the hub 102 may choose to select all EDI schemas for all types of transactions, such as purchase orders, bills of lading, invoices, payrolls, or the like, to the spokes 104. Although the communications between the hub 102 and the spokes 104 can be a private or public communications network, a wired or wireless network, the spokes 104 typically lack the hardware resources to handle large amount of EDI schemas sent from the hub 102. In addition, the type and bandwidth of computing network communications for the spokes 104 are not equipped to handle such demand imposed by the thousands of EDI schemas, which can reach several Gigabytes in data size. [0017] Referring now to FIG. 2, a block diagram illustrates a structured EDI schema using XML according to an embodiment of the invention. As discussed above, related practices would represent EDI schema using a simplified, linear, or flat configuration. Table 1 illustrates three EDI transactions in a structured EDI schema embodying aspects of the invention in the left column and the corresponding three transactions in the traditional EDI representation: [0018] As illustrated, the flat EDI schema uses more characters and thus occupies more data size than a structured EDI schema in the left column. In one embodiment, the structure of EDI schemas is represented using XML which enables faster processing during runtime and easy configuring, editing, and modifying by users using known XML editing tools. [0019] In one example, an EDI schema is identified by a DocType, which may include a combination of namespace and root node name. In one example, DocType is defined as TargetNamespace '#' RootNodeName. In the example where X12 standard is used, Xl2 schemas use the following format: X12 Schemas = X12_{Version}_{TsId}, which indicates that: 1). all X12 schemas have a root node name that starts with X12; 2). "Version" represents the version information of the document, and it is a dynamic piece of information which is configuration or instance driven; and 3). "Tsld" stands for "transaction ID" of the document being processed and is always read from the input instance. [0020] As another example, another well-known standard, EDIFACT, includes the following format for representing the EDIFACT schemas: EDIFACT Schemas = Efact_{Version}_{Tsid}, which indicates that: 1). all EDIFACT schemas have root node name that starts with Efact; 2). " Version" represents the version information of the document, and it is a dynamic piece of information which is configuration or instance driven; and 3). "Tsld" stands for "transaction ID" of the document being processed and is always read from the input instance. [0021] As shown in FIG. 2, an EDI schema 202 in a structural overview may include one or more root nodes 204. Each root node 204 includes a sequence of loops 206 and segments 208 as children. Loops 206 may include one or more nested sub-loops 210 or sub-segments 212. [0022] Similarly, the segment 208 may include one or more component data elements 214 and data elements 216. In one embodiment, an XML payload schema representing an EDI schema may possess the following structure: [0023] In one embodiment, in modeling the EDI schemas using XML, a plurality of schema rules are applied to onfigure the XML schema. For example, the plurality of rules may include: 1. One or more elements (e.g., loop, segment, or the like) are at each level with no attributes. 2. Every ComplexType would use 'sequence' compositor. In one example, the ComplexType is a construct for modeling hierarchical data entities. Each ComplexType may use "sequence", "choice" or "any" compositor to group its children, and each compositor may be used according to the following: a) Sequence - the children should occur in a specific order within an XML instance b) Choice - only one of the children can appear in an XML instance c) Any - children can appear in any order in an XML instance In one embodiment, an EDI schema uses only the sequence compositor. In an alternative embodiment, "choice" and "any" compositor would not be used. The ComplexType may only be included elements as children. 3. Starting from the root node of the document, any element that includes substring "Loop" would be considered a Loop element. Otherwise, it would be considered a segment (see additional discussion below). 4. Once a segment has been identified, substrings of the segment will not be identified. 5. Segments can have children and grand-children in die structured XML schema. For example, only descendants at distance 1 and 2 from the segment node would be permitted as part of the structure. 6. One or more annotations are generated to represent the rules in the EDI schemas. For example, the annotations may be used to represent one or more of the following: a) Cross field validation rules; b) Trigger field information, to be used with schemas associated with compliance with Health Insurance Portability and Accountability Act (HIPAA); c) Reference designator; d) Split point information rules. For example, the split point information indicates information when the EDI schema or EDI transactions satisfying requirements of EDI schemas have split into multiple sub-documents. [0024] In one embodiment, the XML schema is structured using one or more two- or three-character tags. FIG. 3 is a diagram illustrating a XML schema embodying aspects of the invention. For example, a pane] 302 illustrates one or more two- or three-character tags. For example, tags include "ST", "BEG", "CUR". [0025] In one embodiment, based on the name of the segment element, the first three characters may be considered as a tagld. In an alternative embodiment, if the third character of the three-character tag is a "„" character, the segment ID would only be the first two characters. In addition, if one of the two characters includes a "-" character, a compilation error would occur. For instance: a) "BEG_BeginTransaction" means the Segment ID is BEG; b) "N l_850Segment" means the Segment ID is NI; c) "Nabc" means a invalid segment; d) "Nl Loop" means this is a loop and not a segment; and e) "N_Loop" means this is not an invalid segment but a loop. [0026] In another embodiment, one or more special rules may apply to a set of segment tags. For example, tags such as "ISA", "IEA", etc. have special significance and they are called control segments. Similarly, tags such as "ST" and "SE" are both control and data segments. The list below provides an exemplary set of control segment tags: ISA GS ST SE GE IEA UNOA UNB UNG UNH UNT UNE UNZ [0027] In another example, embodiments of the invention enhance the functionality of EDI schemas by accounting for one or more rules using annotations. For example, in handling one or more cross field validation rules, rules are expressed as annotations at segment level nodes. Every segment includes an optional list of rules, which are also known as RuleSet. For example, a panel 304 illustrates one or more annotation tags in a structured XML schema. As an illustration, a set of exemplary rules are described in the following paragraphs: [0028] Paired/Multiple - (all, absent) - Either all subject names are present or absent. For example: [0029] Required - (grouped, absent) - At least one of the subjects is required: [0031] Conditional - (all, value) - If qualifier present, all subjects are required: [0033] Unlike previous representation or model of EDI schemas, embodiments of the invention provide a rich set of information for describing rules associated with EDI schemas using XML. [0034] As illustrated above, each rule has a "subject" attribute, an optional qualifier attribute, and a list of subject elements. For example, each of the rules is defined based on values of (subjects, qualifier) pairs: [0035] In one embodiment, the operands of a rule are data elements found within a segment. In this embodiment, during the rule evaluation, a specific value of an operand is not needed. Rather, what is needed is the information whether the data element was valued or not. Using the system 100 in FIG. 1 as an example, during parsing or serialization by a parser/serializer 112, on encountering a segment, the parser/serializer 112 may keep track of the data elements that had a non-blank value. After segment processing is over, the parser/serializer 112 may be able to evaluate all rule operands and hence execute the RuleSet. In the situation where errors occurred in processing the rule operands, one or more error codes are issued. As an example, an exemplary set of suitable error codes is described below corresponding to particular rule violations: Error code 2 - Conditional required data element missing - This would be reported when a Conditional rule is violated. The reported field number would be the one that is the first one (in the order defined in rule) which is absent. Error code 10 - Exclusion condition violated - This would be reported when an Exclusion rule is violated. The reported field number would be the first one (in the order defined in rule) that makes at least 2 fields'valued. Error code 14 - (BTS-EDI specific) - Cross field validation rule violated - This error would be raised for all other kinds of rules and would be raised under the following circumstances: a) Paired rule - The reported field number would be the one that is the first one which is absent; b) Required rule - This can be violated only if all subjects are absent. In this type of scenario, the first field mentioned in the rule would be reported as having caused the violation; c) List rule - This can be violated when qualifier is present and all subjects are absent. In such case, the first field mentioned in the rule would-be reported as having caused the violation. [0036] Also, in modeling the EDI schemas, embodiments of the invention proper consider the various data types include in EDI schemas. As an example, one or more data types in X12 format are described below: [0037] A. X12 data types: [0038] X12 defines a number of data types. Such types would be recognized by parser/serializer. They would have the capability to validate such types and perform any necessary transformation. However, a document schema can have any kind of simple type associated with it. If it is not an Edi data type, it would be validated codes, routings, computer-executable instructions, such as XmlValidatingReader, depending on schema validation flag being turned on or not. t. "N" - This is an integer data type with an optional length restriction. A simple element of this type, should have a simple type that is a restriction on a type with local name "N". And "N" is essentially an xs:string. 2. "Nn" - This is an integer type with an implied decimal point, specified by n > 0. So if Type is N2 - then parser would convert 1234 to 12.34. Likewise, V2.34 would be converted to 1234 by the serializer. If the decimal point is not encountered or length restriction is not followed, an appropriate Edi error code would be raised. A simple element of this type, should have a simple type that is a restriction on a type with local name "N2", for instance. 3. "ID" - This is an enumeration data type with optional length restrictions. A simple element of this type, should have a simple type that is a restriction on a type with local name "ID". And "ID" is essentially an xs.string. If the list of enumeration is empty, any data value would be allowed. 4. "AN" - This is an alphanumeric data type with length restrictions. A simple element of this type, should have a simple type that is a restriction on a type with local name "AN". And "AN" is essentially an xs:string. 5. "R" - This is a real number. A simple element of this type, should have a simple type that is with local name "R". And "R" has the format [sign]integral-digits[.[fractional-digits]] where 6. "Date" - This is a date data type. A simple element of this type should have a simple type with local name "date". The format is CCYYMMDD. 7. "Time" - A simple element of this type should have a simple type with local name "time". The format is HHMM[[SS][d[d]]]. [0040] B. EDIFACT Data Type: [0041] Similarly, in describing schemas in EDIFACT format, an EDIFACT schema defines a number of data types such as one of the following: 1. "a" - This is an alphabetic data type with a length restriction. A simple element of this type, should have a simple type that is a restriction on a type with local name "a". And "a" is essentially an xs:string. -