What is EDI?

Electronic Data Interchange (EDI) is the computer-to-computer exchange of business documents in a standard electronic
format between business partners.
By moving from a paper-based exchange of business document to one that is electronic, businesses enjoy major benefits such
as reduced cost, increased processing speed, reduced errors and improved relationships with business partners.
Computer-to-computer EDI replaces postal mail, fax and email. While email is also an electronic approach, the
documents exchanged via email must still be handled by people rather than computers. Having people involved slows
down the processing of the documents and also introduces errors. Instead, EDI documents can flow straight through to
the appropriate application on the receivers computer (e.g., the Order Management System) and processing can begin
immediately.
A typical manual process looks like this, with lots of paper and people involvement:

The EDI process looks like this no paper, no people involved:

Business documents These are any of the documents that are typically exchanged between businesses. The most
common documents exchanged via EDI are purchase orders, invoices and advance ship notices. But there are many,
many others such as bill of lading, customs documents, inventory documents, shipping status documents and payment
documents.
Standard format Because EDI documents must be processed by computers rather than humans, a standard format must
be used so that the computer will be able to read and understand the documents. A standard format describes what
each piece of information is and in what format (e.g., integer, decimal, mmddyy). Without a standard format, each
company would send documents using its company-specific format and, much as an English-speaking person probably
doesnt understand Japanese, the receivers computer system doesnt understand the company-specific format of the
senders format.

There are several EDI standards in use today, including ANSI, EDIFACT, TRADACOMS and ebXML. And, for each
standard there are many different versions, e.g., ANSI 5010 or EDIFACT version D12, Release A. When two businesses
decide to exchange EDI documents, they must agree on the specific EDI standard and version.
Businesses typically use an EDI translator either as in-house software or via an EDI service provider to translate the
EDI format so the data can be used by their internal applications and thus enable straight through processing of documents.

Business partners The exchange of EDI documents is typically between two different companies, referred to as business
partners or trading partners. For example, Company B may buy goods from Company A. Company B sends orders to
Company B. Company A and Company B are business partners. And below flow diagram shows the typical
Transaction Exchange between 2 companies A & B.


What Comprises an EDI Document?
An EDI document is comprised of data elements, segments and envelopes that are formatted according to the rules of a
particular EDI standard.
When you create an EDI document, such as a purchase order, you must adhere to the strict formatting rules of the standard
you are using. These rules define exactly where and how each piece of information in the document will be found. That way,
when the EDI translator on the receiving computer reads an incoming EDI purchase order, it will immediately understand
where to find the buyers company name, the purchase order number, the items being ordered, the price for each item, etc.
Then, that data will be fed into the receivers order entry system in the proper internal format without requiring any manual
order entry.
The graphic below shows a sample purchase order in printed form and how it would look once its translated into the ANSI
and EDIFACT EDI formats.

In the EDI language, a single business document, such as a purchase order, invoice or advance ship notice, is called a
transaction set or message. And, a transaction set is comprised of data elements, segments and envelopes.

What is a Data Element?
The data elements in an EDI Transaction Set are the individual items of information within the document.
For example, within many documents, such as the purchase order and invoice, you will find data elements such as city, state,
country, item number, quantity and price.
Each data element in a transaction set is defined in the EDI Standard by the type of data it represents. For example, it would
be important to distinguish numeric data from text data or calendar dates. The data element definition will describe:
Data type of numeric, alphanumeric, date or time
Minimum and maximum length
Code values, if applicable, that must be observed with a particular type of data. For example, if the data element is unit
cost, you would use a currency code element as well to allow you to indicate what currency (e.g., US dollars or euros)
is being used in the unit cost field
Elements are combined into segments.
What is a Segment?
A segment in an EDI transaction set is a group of like data elements.
If you were filling out information on a purchase order, you would expect to see groups of related data. For example, look at
the diagram below of a paper purchase order in which only one item is being ordered. Note that there are four sections,
each providing a different set of information:

In an EDI document, each section is described by a particular segment. Below is the set of EDI segments that would
describe the purchase order above when using the ANSI standard. Each segment begins with a segment ID (e.g., ST, BEG,
N1) that describes the type of data elements that follows. The elements within each segment are separated by a data element
separator, in this case the *.
ST*850*1001 ST, to indicate start of a transaction set in this case the 850 purchase order

BEG*00*SA*4768*65*20120930 BEG, to indicate the beginning of the PO, specifically (1)
N1*SO*XYZ Company N1, a name segment (2)
N3*123 Main Street N3, to provide street address

N4*Fairview*CA*94168 N4, to provide city/state/zip

PO1*1*100*EA*27.65**VN*331896-42 PO1, to provide line item detail (3)
CTT*1*100 CTT, to provide summary data for the PO (4)
SE*8*1001 SE, to indicate the end of the PO


For each type of business document, the EDI standard documentation defines:
The segments that may be included and which ones are mandatory, optional and/or conditional (i.e. must be included only
if another segment or element is included)
For each segment, the elements that may be included for every piece of information in a paper document there is a
corresponding EDI element. These elements are defined in the standards dictionary and each standard has its own
dictionary
The required sequence of the segments and elements
How many times a segment may be repeated
Now, once all the segments are collected into a prescribed sequence, they form a complete electronic document, or
transaction set. Next, the transaction sets must be put into envelopes in preparation for transmission to your partners.
What are EDI Envelopes?
EDI document transmission uses a system of three envelopes to house your transaction sets Message envelope,
Group envelope and I nterchange envelope.
Just as paper business documents are sent in envelopes and its possible to mail many documents in a single envelope, EDI
documents are exchanged using several envelopes.
Each transaction set is placed in its individual envelope
A group of transaction sets e.g., a group of purchase orders is placed in a group envelope. (The group envelope is
mandatory in ANSI and optional in EDIFACT.)
All group envelopes being sent from one sender to one receiver are placed in an Interchange envelope
See the diagram below:

An envelope is formed by a pair of segments that define the beginning and end of the appropriate
section. Using the EDIFACT standard as the example, the Transaction Set Envelope uses the UNH
and UNT segments, the Group Envelope uses the UNG and UNE segments and the Interchange
Envelope uses the UNA/UNB and UNZ segments. In each case, the S indicates the start of the
envelope and the E indicates the end of the envelope. The diagram below illustrates the three
levels of envelopes that would surround a single EDI purchase order.

How Does EDI work?
There are 3 steps to sending EDI documents Prepare the documents, Translate the documents into EDI format, Transmit
the EDI documents to your partner.
Step 1: Prepare the documents to be sent
The first step is to collect and organize the data. For example, instead of printing a purchase order, your system creates an
electronic file with the necessary information to build an EDI document. The sources of data and the methods available to
generate the electronic documents can include:
Human data entry via screens
Exporting PC-based data from spreadsheets or databases
Reformatted electronic reports into data files
Enhancing existing applications to automatically create output files that are ready for translation into an EDI standard
Purchasing application software that has built-in interfaces for EDI files
Step 2: Translate the documents into EDI format
The next step is to feed your electronic data through translator software to convert your internal data format into the EDI
standard format using the appropriate segments and data elements. You can purchase EDI translation software that you
manage and maintain on your premises. This requires specialized mapping expertise in order to define how your internal
data is to be mapped (i.e. correlated) to the EDI data. Translation software is available to suit just about any computing
environment and budget, from large systems that handle thousands of transactions daily to PC-based software that need
only process a few hundred transactions per week.
Alternatively, you can use the translation services of an EDI service provider. In that case, you send your data to the
provider, who handles translation to and from the EDI format on your behalf.
Step 3: Connect and Transmit your EDI documents to your business partner
Once your business documents are translated to the appropriate EDI format they are ready to be transmitted to your
business partner. You must decide how you will connect to each of your partners to perform that transmission. There are
several ways, the most common of which include 1) to connect directly using AS2 or another secure internet protocol, 2)
connect to an EDI Network provider (also referred to as a VAN provider) using your preferred communications protocol
and rely on the network provider to connect to your business partners using whatever communications protocol your
partners prefer, or 3) a combination of both, depending on the particular partner and the volume of transactions you expect
to exchange.

A common business process is the exchange of purchase orders and invoices. So, lets compare how this is done using paper
or EDI.
In the paper-based method, the following process typically occurs:
The inventory system automatically notifies the buyer to place an order, or, after querying the inventory system, the buyer
determines that an order needs to be created
The buyer enters data onto the screen of a purchasing system to create the PO, prints and mails it
After several days, the vendor receives the PO and manually enters it into the sales order system
The vendor prints an invoice and encloses it with the shipment and/or sends it separately by mail
The buyer manually enters the invoice into the Accounts Payable system
The exchange of paper documents can add a week to the process. If there are errors caused by manual data entry, the time
can be greatly increased.
Now compare that with the EDI process:
The buyers procurement system, which utilizes EDI software, automatically generates and sends an EDI-formatted PO
when inventory reaches the critical level
Within minutes the vendors sales order system, utilizing EDI software, receives the EDI PO, notifies the shipping
department to ship the goods and generates an EDI invoice to be transmitted directly to the buyers accounts payable
system
The EDI process can be completed within hours.

Benefits of EDI:
EDI continues to prove its major business value by lowering costs, improving speed, accuracy and business efficiency. The
greatest EDI benefits often come at the strategic business level.
Expenses associated with paper, printing, reproduction, storage, filing, postage and document retrieval are all reduced or
eliminated when you switch to EDI transactions, lowering your transaction costs by at least 35%
Errors due to illegible faxes, lost orders or incorrectly taken phone orders are eliminated, saving your staff valuable time
from handling data disputes
EDI can speed up your business cycles by 61%. Exchange transactions in minutes instead of the days or weeks of wait
time from the postal service
Enables real-time visibility into transaction status. This in turn enables faster decision-making and improved
responsiveness to changing customer and market demands, and allows businesses to adopt a demand-driven business
model rather than a supply-driven one
Shortens the lead times for product enhancements and new product delivery
Streamlines your ability to enter new territories and markets. EDI provides a common business language that facilitates
business partner onboarding anywhere in the world
Promotes corporate social responsibility and sustainability by replacing paper-based processes with electronic
alternatives. This will both save you money and reduce your CO2 emissions
Common Exchanging Methods of EDI:
Electronic data interchange (EDI) is one of the most common forms of structured exchange
of business documents between organizations by electronic means. There are many different types
of EDI and a range of approaches to enabling EDI across a trading community. Whether looking at
EDI for the first time or expanding an existing EDI infrastructure to support a variety of business
partners across the globe, there is a method of utilizing EDI that will suit your business needs,
technical capabilities and budget. Many larger companies adopt hybrid EDI solutions to connect
with their business partners, dependent on size, importance and frequency of their transactions.
EDI via VAN [Value-Added Network]
When 2 Business Partners cant directly exchange Transactions, probably due to software
restrictions or security restrictions, they can use VAN. VAN will act as a mediator between 2
partners. Partners can FTP send or receive transactions to VAN. Below is the simple example of
transaction exchange from VAN. Sterling Commerce, GXS are some examples of VAN providers.
Company A sends Transaction to VAN mail slot.
Company Bs FTP server or B2B software polls on VAN mail slot and receives Transaction.
Once Transaction is processed, Company B will put response transaction in VAN mail slot.
Company A will receive Response Transaction from VAN.
EDI via AS2 [HTTP / HTTPS]
AS2 is an Internet communications protocol that enables data to be transmitted securely over the
Internet. EDI via AS2 delivers the functionality of EDI with the ubiquity of Internet access.
Transactions will be exchanged directly between 2 Partners.

EDI Document Standards:
Below are different EDI Document Standards
EANCOM
This standard was originally conceived in 1987 by the EAN General Assembly and was to be
developed on the then emerging international UN/EDIFACT standard. The EANCOM messages,
maintained by GS1, are more detailed in nature compared to the TRADACOMS message set.
EANCOM was originally developed for the retail sector and has subsequently grown to become the
most widely used UN/EDIFACT subset and is now found in a variety of other industry sectors such
as healthcare, construction and publishing.
HIPAA
The Health Insurance Portability and Accountability Act was enacted by the U.S congress in 1996.
A key component of HIPAA is the establishment of national standards for electronic health care
transactions and national identifiers for providers, health insurance plans and employers. The
standards are meant to improve the efficiency and effectiveness of the North American health care
system by encouraging the widespread use of EDI in the U.S health care system. The HIPAA EDI
transaction sets are based on X12 and the key message types are described below.

EDI Health Care Claim Transaction set (837)
EDI Retail Pharmacy Claim Transaction (NCPDP Telecommunications Standard
version 5.1)
EDI Health Care Claim Payment/Advice Transaction Set (835)
EDI Benefit Enrollment and Maintenance Set (834)
EDI Payroll Deducted and other group Premium Payment for Insurance Products
(820)
EDI Health Care Eligibility/Benefit Inquiry (270)
EDI Health Care Eligibility/Benefit Response (271)
EDI Health Care Claim Status Request (276)
EDI Health Care Claim Status Notification (277)
EDI Health Care Service Review Information (278)
EDI Functional Acknowledgement Transaction Set (997)
ODETTE
The Organization for Data Exchange by Tele Transmission in Europe is a group that represents the
interests of the automotive industry in Europe. They are the equivalent of the Automotive Industry
Action Group (AIAG) in North America. The organization develops tools and recommendations that
improve the flow of goods, services product data and business information across the whole
automotive value chain. ODETTE has been responsible for developing communications standards
such as OFTP and OFTP2.0, constant improvement processes such as Materials Management
Operations Guideline / Logistics Evaluation (MMOG/LE) and automotive-specific document
standards as defined below.

DELINS Delivery Forecast / Delivery
EXHAND For Delivery Schedule Exception Handling
CALDEL JIT Delivery
SYNCRO Sequenced Delivery
KANBAN KANBAN Delivery
FORDIS Ready for Dispatch Advice
AVIEXP Dispatch Advice
INVOIC Invoice
STOACT Inventory Report
TRINAD Forwarding Instruction
CONSUM Consignment Consolidation
ORDERR Purchase Order
ORDCHG Order Change
REPORD Order Response
PRILST Price List Based
REMADV Remittance Advice
STATAC Account Statement
SWIFT
The Society of Worldwide Interbank Financial Telecommunication was formed in 1973 and is
headquartered in Brussels. SWIFT operates a worldwide financial messaging network which
exchanges messages between banks and financial institutions. SWIFT also markets software and
services to financial institutions, much of it for use on the SWIFTNet Network. SWIFTNet is the
infrastructure used to exchange these documents and FIN, InterAct and FileAct are used to encode
the SWIFT documents for transmission. The majority of interbank messages use the SWIFT
network. As of November 2008, SWIFT linked 8740 financial institutions across 209 countries. The
SWIFT document standard is split into four areas, Payments, Trade Services, Securities and
Trading.
Tradacoms
This is an early standard for EDI and was primarily used in the UK retail sector. It was originally
introduced in 1982 as an implementation of the UN/GTDI syntax, one of the precursors of
EDIFACT, and was maintained and extended by the UK Article Numbering Association, now called
GS1 UK. The standard is more or less obsolescent since the development of it effectively ceased in
1995 in favor of the EDIFACT EANCOM subsets. Despite this it has proved durable and the majority
of the retail EDI traffic in the UK still uses it today.
VDA
This organization develops standards and best practices to serve the needs of companies within
the German automotive industry. The VDA has developed over thirty messages to meet the need
of companies such as VW, Audi, Bosch, Continental and Daimler AG.
VICS
The Voluntary Inter-industry Commerce Standard is used by the general merchandise retail
industry across North America. It is a subset of the ANSI ASC X12 national standard. VICS EDI is
being utilized by thousands of companies, department and specialty retail stores, mass
merchandisers and their respective suppliers. In 1988 GS1 US became the management and
administrative body for VICS EDI. GS1 US also manages the ASC X12 derived Uniform
Communication Standard (UCS) for the grocery industry and Industrial/Commercial Standard (I/C)
for the industrial sector.
ANSI ASC X12
In 1979, the American National Standards Institute (ANSI) chartered the Accredited Standards
Committee (ASC) X12 to develop uniform standards for inter-industry electronic exchange of
business transactions, namely electronic data interchange. ANSI X12 was originally conceived to
support companies across different industry sectors in North America however today there are
more than 300,000 companies worldwide using X12 EDI standards in daily business transactions.
ASC X12 also contributes to UN/EDIFACT messages that are used widely outside of the United
States.
There are different versions of ANSI i.e... 2000, 2001, 2002 3010, 3020, 3030 4010, 4020 5010, 5020.
Some ANSI X12 Transaction set examples:

850 Purchase Order
855 Purchase Order Acknowledgment
856 Advance Ship Notice
860 Purchase Order Change Request
865 Purchase Order Change Acknowledgment
867 Product Transfer and Resale Report
844 Product Transfer Account Adjustment
845 Price Authorization Acknowledgment/Status
849 Response to Product Transfer Account Adjustment
810 Invoice
997 Functional Acknowledgment
UN/EDIFACT
United Nations/Electronic Data Interchange for Administration, Commerce and Transport is the
international standard that was developed by the United Nations. The work of maintenance and
further development of this standard is done through the United Nations Centre for Trade
Facilitation and Electronic Business (UN/CEFACT) under the UN Economic Commission for Europe.
The EDIFACT standard provides a set of syntax rules to structure, an interactive exchange protocol
and provides a set of standard messages which allow multi-country and multi-industry exchange of
electronic business documents. EDIFACT is widely used across Europe, mainly due to the fact that
many companies adopted it very early on. EDIFACT has seen some adoption in the ASPAC region,
however, there are currently more XML-based standards being used in this particular region today.
There are different versions in EDIFACT i.e. 00A, 00B, 01A 901, 902, 911 93A, 94A, 94B, 95A
Some EDIFACT Transaction set examples:

ORDERS Purchase order message
ORDCHG Purchase order change request message
ORDRSP Purchase order response message
DELFOR Delivery schedule message
DESADV Dispatch advice message
SLSRPT Sales data report message
INVOIC Invoice message
INVRPT Inventory report message
RosettaNet
Founded in 1998, RosettaNet is an independent, self-funded, non-profit consortium dedicated to
the development of XML-based standard electronic commerce interfaces to align the processes
between supply chain partners on a global basis.
This consists of a consortium of major computer, consumer electronics, semi-conductor
manufacturers, telecommunications and logistics companies working together to create and
implement industry-wide, open e-business process standards. These standards form a common e-
business language, aligning processes between supply chain partners on a global basis. The
RosettaNet document standard is based on XML and defines message guidelines, business
processes interface and implementation frameworks for interactions between companies. Using
RosettaNet Partner Interface Processes (PIPs), business partners of all sizes can connect
electronically to process transactions and move information within their extended supply chains.
Some Rosettanet Transaction Sets:

PIP3A4 Request Purchase Order
PIP 3A5 Query Order Status
PIP 3A8 Request Purchase Order Change
PIP 3A7 Notify of Purchase Order Update
PIP 3B2 Notify of Advance Shipment
PIP 4B3 Consumption Notification Order
PIP 4C1 Inventory Report
PIP 4A3 Threshold Release
PIP 4A5 Forecast Reply


ELEMENTS OF ROSETTANET

Partner Interface Processes (PIPs)
A messaging system
Partner Interface Processes

The sequence of steps required to execute an atomic business process between
two supply chain partners
Contain nonproprietary business processes
Stand as discrete units of work that can be attached and built into other PIPs to
achieve a larger business outcome
Clusters and Segments
PIPs are designed to fit into seven Clusters, representing the core business
processes or backbone of the trading network. Each Cluster is broken down into
Segments -- cross-enterprise processes involving more than one type of trading
partner. Within each Segment are individual PIPs

Few Important Points to NOTE
More than 100 PIPs grouped into clusters and then to segments
For example, Cluster 3 is Order Management and Segment 3A in this cluster is about Quote and Order Entry
As an example of the PIPs in this segment PIP3A4: Manage Purchase Order
PI P 3A4: Manage Purchase Order
Buyer creates a Purchase Order and sends it to the Seller
Seller receives the Purchase Order and returns a Purchase Order Acceptance
The Buyer determines success or failure based on message content
Example: PIP3A4 Request Purchase Order
Cluster 3: Order Management
Segment 3A: Quote & Order Entry
4th PIP
Doing Business through RosettaNet
In order to do electronic business within the RosettaNet framework, there are a number of steps the partners have to go
through
First, the supply chain partners come together and analyze their common inter-company business scenarios (i.e., public
processes), that is, how they interact to do business with each other, which documents they exchange and in what
sequence
Then they re-engineer these processes to define the electronic processes to be implemented within the scope of the
RosettaNet Framework
An electronic business process includes both the interactions between partner companies, and the private processes
within the company
RosettaNet provides guidelines only for PIPs which are the public part of the inter-company processes
Necessary to differentiate
Public Business Processes: The process among the trading partners
RosettaNet defines and fixes Public Business Processes in terms of PIPs
Private Business Processes: The business processes internal to the company

An Example
Consider, for example, a scenario where a buyer requests the price and availability of some products from a seller
(PIP3A2)
After receiving the response, the buyer initiates a Purchase Order Request (PIP3A4)
The seller, on the other hand, after acknowledging the Purchase Order Request, sends an invoice notification (PIP3C3) to
the buyer
The seller sends a transportation request (PIP3B1) to the shipper (There is a third party in this scenario, which is a
shipper)
The shipper, after shipment of the goods, sends the status of the shipment (PIP3B3)
When buyer receives the shipment, it sends a shipment receipt notification (PIP4B2) to the seller.
Finally, the seller prepares a billing statement and notifies the buyer (PIP3C5)
RosettaNet Messaging Structure
Execution of PIPs involves exchanging messages between the parties, and RosettaNet provides a Business Message
structure for this purpose
RosettaNet business messages (also termed as action or service messages) consist of a message header and a message
body
Both the header and the body are complete, valid XML documents
The header and the body are encoded within a multipart/Related MIME message
RosettaNet Messaging
The message content is specified in individual PIPs
Each PIP has one or more "actions" that are described by means of an individual DTD or schema
RosettaNet Implementation Framework (RNIF) specifies and provides for a consistent mechanism to digitally sign and/or
encrypt all RosettaNet messages (as needed), independent of the transfer protocol, PIP and the specific business
document being exchanged
It also specifies a reliable messaging mechanism based on "Acknowledgements"
RosettaNet Transport
The PIP business message is encapsulated into a RosettaNet protocol message termed as "RosettaNet Object
The RosettaNet Object is composed of a version and content length header, content comprising a business action
message, and a digital signature length followed by a digital signature trailer
"RosettaNet Object is encapsulated into a message of HTTP protocol and send as a as a direct HTTP message
The RosettaNet Business Message

TREE STRUCTURE FROM MESSAGE GUI DELI NE
1 Preamble
2 |-- standardName.GlobalAdministeringAuthorityCode
3 |-- standardVersion.VersionIdentifier
1 Delivery Header
2 | isSecureTransportRequired.AffirmationIndicator
3 | messageDateTime.DateTimeStamp
4 | messageReceiverIdentification.PartnerIdentification
5 | | domain.FreeFormText
6 | | GlobalBusinessIdentifier
7 | | locationID.Value
8 | messageSenderIdentification.PartnerIdentification
9 | | domain.FreeFormText
1 | | GlobalBusinessIdentifier
1 | | locationID.Value
1 | messageTrackingID.InstanceIdentifier
1 ServiceHeader
2 | ProcessControl
3 | | ActivityControl
4 | | | BusinessActivityIdentifier
5 | | | MessageControl
6 | | | | fromRole.GlobalPartnerRoleClassificationCode
7 | | | | fromService.GlobalBusinessServiceCode
8 | | | | inReplyTo.ActionControl
9 | | | | | ActionIdentity
10 | | | | | | GlobalBusinessActionCode
11 | | | | | | messageStandard.FreeFormText
12 | | | | | | standardVersion.VersionIdentifier
13 | | | | | messageTrackingID.InstanceIdentifier
14 | | | | Manifest
15 | | | | | Attachment
16 | | | | | | description.FreeFormText
17 | | | | | | GlobalMimeTypeQualifierCode
18 | | | | | | UniversalResourceIdentifier
19 | | | | | numberOfAttachments.CountableAmount
20 | | | | | ServiceContentControl
21 | | | | | | Choice
22 | | | | | | | ActionIdentity
23 | | | | | | | | GlobalBusinessActionCode
24 | | | | | | | | messageStandard.FreeFormText
25 | | | | | | | | standardVersion.VersionIdentifier
26 | | | | | | | SignalIdentity
27 | | | | | | | | GlobalBusinessSignalCode
28 | | | | | | | | VersionIdentifier
29 | | | | toRole.GlobalPartnerRoleClassificationCode
30 | | | | toService.GlobalBusinessServiceCode
31 | | GlobalUsageCode
32 | | partnerDefinedPIPPayloadBindingId.Proprietary ReferenceIdentifier
33 | | pipCode.GlobalProcessIndicatorCode
34 | | pipInstanceId.InstanceIdentifier
35 | | pipVersion.VersionIdentifier
36 | | QualityOfServiceSpecification
37 | | | QualityOfServiceElement
38 | | | | QualityOfServiceClassificationCode
39 | | | | Value
40 | | Choice
41 | | KnownInitiatingPartner
42 | | | | PartnerIdentification
43 | | | | | domain.FreeFormText
44 | | | | | GlobalBusinessIdentifier
45 | | | | | locationID.Value
46 | | UnknownInitiatingPartner
47 | | | | PartnerIdentification
48 | | | | | domain.FreeFormText
49 | | | | | GlobalBusinessIdentifier
50 | | | | | locationID.Value
51 | | | | UniformResourceLocator

XML:
XML stands for Extensible Markup Language
XML is a markup language much like HTML
XML was designed to carry data, not to display data
XML tags are not predefined. You must define your own tags
XML is designed to be self-descriptive
XML was created to structure, store, and transport information.
XML documents form a tree structure that starts at "the root" and branches to "the leaves".
XML Document Example
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to> Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

XML is Used to Create New I nternet Languages
A lot of new Internet languages are created with XML.
Here are some examples:
XHTML
WSDL for describing available web services
WAP and WML as markup languages for handheld devices
RSS languages for news feeds
RDF and OWL for describing resources and ontology
SMIL for describing multimedia for the web
XML Syntax Rules:
All XML Elements Must Have a Closing Tag

o <p>This is a paragraph.</p>
XML Tags are Case Sensitive
o <Message>This is incorrect</message>
o <message>This is correct</message>
XML Elements Must be Properly Nested
o <b><i>This text is bold and italic</b></i>
o <b><i>This text is bold and italic</i></b>
XML Documents Must Have a Root Element
<root>
<child>
<subchild>.....</subchild>
</child>
</root>
XML Attribute Values Must be Quoted
o <note date=12/11/2007> </note> wrong
o <note date="12/11/2007"> </note> correct
Entity References
Some characters have a special meaning in XML. If you place a character like "<" inside an
XML element, it will generate an error because the parser interprets it as the start of a new
element. This will generate an XML error:

o <message>if salary < 1000 then</message>
To avoid this error, replace the "<" character with an entity reference: <message>if salary &lt;
1000 then</message>
There are 5 predefined entity references in XML:

o &lt; < less than
o &gt; > greater than
o &amp; & ampersand
o &apos; ' apostrophe
o &quot; " quotation mark
Well Formed XML
XML documents that conform to the syntax rules above are said to be "Well Formed"
XML documents.
XML DTD:
An XML document with correct syntax is called "Well Formed".
An XML document validated against a DTD is "Well Formed" and "Valid".
The purpose of a DTD is to define the structure of an XML document. It defines the structure with a list
of legal elements:
<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
The DTD above is interpreted like this:
!DOCTYPE note defines that the root element of the document is note
!ELEMENT note defines that the note element contains four elements: "to, from, heading, body"
!ELEMENT to defines the to element to be of type "#PCDATA"
!ELEMENT from defines the from element to be of type "#PCDATA"
!ELEMENT heading defines the heading element to be of type "#PCDATA"
!ELEMENT body defines the body element to be of type "#PCDATA"
Using DTD for Entity Declaration:
A doctype declaration can also be used to define special characters and character strings, used in the
document:
Example
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE note [
<!ENTITY nbsp "&#xA0;">
<!ENTITY writer "Writer: Donald Duck.">
<!ENTITY copyright "Copyright: W3Schools.">
]>

<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
<footer>&writer;&nbsp;&copyright;</footer>
</note>
Why Use a DTD?
With a DTD, your XML files can carry a description of its own format.
With a DTD, independent groups of people can agree on a standard for interchanging data.
With a DTD, you can verify that the data you receive from the outside world is valid.
XML Schema:
An XML Schema describes the structure of an XML document, just like a DTD.
An XML document with correct syntax is called "Well Formed".
An XML document validated against an XML Schema is both "Well Formed" and "Valid".
XML Schema is an XML-based alternative to DTD:
<xs:element name="note">

<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>

</xs:element>
The Schema above is interpreted like this:
<xs:element name="note"> defines the element called "note"
<xs:complexType> the "note" element is a complex type
<xs:sequence> the complex type is a sequence of elements
<xs:element name="to" type="xs:string"> the element "to" is of type string (text)
<xs:element name="from" type="xs:string"> the element "from" is of type string
<xs:element name="heading" type="xs:string"> the element "heading" is of type string
<xs:element name="body" type="xs:string"> the element "body" is of type string
Everyting is wrapped in "Well Formed" XML.
XML Schemas are More Powerful than DTD
XML Schemas are written in XML
XML Schemas are extensible to additions
XML Schemas support data types
XML Schemas support namespaces
Why Use an XML Schema?
With XML Schema, your XML files can carry a description of its own format.
With XML Schema, independent groups of people can agree on a standard for interchanging data.
With XML Schema, you can verify data.
XML Schemas Support Data Types
One of the greatest strength of XML Schemas is the support for data types:
It is easier to describe document content
It is easier to define restrictions on data
It is easier to validate the correctness of data
It is easier to convert data between different data types
Generating Simple XML Schema:
Look at this simple XML document called "note.xml":
<?xml version="1.0"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
The following example is a DTD file called "note.dtd" that defines the elements of the XML document
above ("note.xml"):
<!ELEMENT note (to, from, heading, body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
The first line defines the note element to have four child elements: "to, from, heading, body".Line 2-5
defines the to, from, heading, body elements to be of type "#PCDATA".
The following example is an XML Schema file called "note.xsd" that defines the elements of the XML
document above ("note.xml"):
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
xmlns="http://www.w3schools.com"
elementFormDefault="qualified">

<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>
The note element is a complex type because it contains other elements. The other elements (to, from,
heading, body) aresimple types because they do not contain other elements. You will learn more about
simple and complex types in the following chapters.
The <schema> element is the root element of every XML Schema:
<?xml version="1.0"?>

<xs:schema>
...
...
</xs:schema>
The <schema> element may contain some attributes. A schema declaration often looks something like
this:
<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
xmlns="http://www.w3schools.com"
elementFormDefault="qualified">
...
...
</xs:schema>
The following fragment:
xmlns:xs="http://www.w3.org/2001/XMLSchema"
indicates that the elements and data types used in the schema come from the
"http://www.w3.org/2001/XMLSchema" namespace. It also specifies that the elements and data types
that come from the "http://www.w3.org/2001/XMLSchema" namespace should be prefixed with xs:
This fragment:
targetNamespace="http://www.w3schools.com"
indicates that the elements defined by this schema (note, to, from, heading, body.) come from the
"http://www.w3schools.com" namespace.
This fragment:
xmlns="http://www.w3schools.com"
indicates that the default namespace is "http://www.w3schools.com".
This fragment:
elementFormDefault="qualified"
indicates that any elements used by the XML instance document which were declared in this schema
must be namespace qualified.

Flat File:
Flat file contains hierarchical data in a record based format.
Flat files metadata is separate from its data, unlike XML.
A flat file contains:
o Records contains fields and composites
o Composites multiple related files [address]
o Fields atomic data [zip code]
Flat file types
o Record identifier present
o No Record identifier present

Flat file examples
- Flat file with Record ID
-Simple [Record ID in Bold]
ADDRESS, XYZ COMPANY, 367 STREET, SACRAMENTO+CA+95467
ADDRESS, ABC CORPORATION, DALAL STREET, NAVIMUMBAI+IN+5040843
-Complex (parent-child relationships)
START*PURCHORD*0002678
BEGINDOC*00*BE*M1Q67GH67*120038793*78972*13245
-12
CURRENCY*BY*USD
Records, Fields and Composites: Example
ADDRESS, ACME HAMMER COMPANY, 123 WILSON STREET, SACRAMENTO+CA+95833


Flat file without Record ID
-Delimited (CSV)
XYZ COMPANY, 367 STREET, SACRAMENTO, CA, 95467
ABC CORPORATION, DALAL STREET, NAVIMUMBAI, IN, 5040843
-Fixed Length
XYZ COMPANY 367 STREET SACRAMENTO CA 95467
ABC CORPOR DALAL STREET NAVIMUMBAI IN 5040843
-Variable Length

o First column in each record specifies the length. Can be different.
o Each record is preceded by two bytes that indicate the length of the record. Records in
the flat file can have different lengths.
o The first two bytes of the records should contain a binary number representing the
length of the record. Max record length is 0xFFFF(Hexadecimal) which is 65535.
o Records can have record identifiers.
o Fields can be identified by the number of bytes from the start of the records and length
of the fields [fixed width].
o Fields can be separated by delimiters.
Delimited Record: Example
-Record delimited by newline character
XYZ COMPANY, 367 STREET, SACRAMENTO+CA+95467
ABC CORPORATION, DALAL STREET, NAVIMUMBAI+IN+5040843

o Record Delimiter = newline
o Filed Delimiter = ,
o Sub Filed Delimiter = +
-Record delimited by ! character
XYZ COMPANY*367 STREET*SACRAMENTO+CA+95467!
ABC CORPORATION*DALALSTREET*NAVIMUMBAI+IN+5040843!

o Record Delimiter =!
o Filed Delimiter = *
o Sub Filed Delimiter = +
Variable Length file: Example

o First two bytes contain the record lenght in binary format.
o Has Record IDs and field delimiter ','.


Advertisement