Pharos XML/EDI Project
Transformation  from  EDIFACT  to  XML

Version 1.0
2000-03-20

Authors:
Gösta Mellquist, Edifact Transport AB. Email: gosta.mellquist@sema.btl.se
Trond Johansen, Sintef. Email: Trond.Johansen@informatics.sintef.no

This report may be downloaded from www.Pharos.NU , select English library.
Direct URL: http://www.edifact-transport.se/library/engbib.html
File name: PHAROS_XML_EDI.ZIP  includes annexes as separate files.

Table of Contents

1.	Executive Summary	3
1.1	Background and work performed	3
1.2	Conclusions	3
1.3	Further Work	3
2.	Introduction	4
2.1	Background on Pharos project	4
2.2	Overview of  Pharos Transformation Method	4
2.3	Benefits and reasons  for Pharos Transformation method.	5
2.4	Summary of other approaches for transformations of EDIFACT to XML	6
2.4.1	Alt. A - Straight conversion Edifact to XML 1:1	6
2.4.2	Alt. B -  Create XML DTD direct from Business model.	7
2.4.3	Alt. C - Creating XML DTD from a UML Domain model	7
2.5	Development of a Transport Domain Model	8
2.6	The issue of  XML tag names	8
3.	Step 1 – From EDIFACT  MIG to Business Model	9
3.1	Illustration of a Pharos Business Model	9
3.2	Transformation from Edifact to Business Model	9
3.3	Additional principles and rules for Pharos Business Model (extract)	10
4.	Step 2 – From Business Model to UML Message Model	11
4.1	UML conceptual terms	11
4.2	Naming Rules	11
4.3	The Message Root Class	12
4.4	Transformation of Sections and Subsections	12
4.5	Associations	13
4.6	Attributes	15
4.7	Attribute Properties	16
5.	Step 3 - From UML Message Model to XML/DTD or XML Schema	17
5.1	Automatic generation	17
5.2	Transformation rules	17
5.3	Sequence	17
6.	Reference List	18
7.	Annexes.	18
7.1	Annex A – Example of a Business Model	18
7.2	Annex B – Example of a UML Message Model	18
7.3	Annex C – Example of a XML/DTD	18
7.4	Annex D – Example of a XML Schema	18
7.5	Annex E – Example of a XML message instance	18

1.	
 Executive Summary
1.1	 Background and work performed
In the ongoing development of metodhologies for using XML for business to business communication  one of the most challenging issues is how to migrate from existing Edifact messages to XML/EDI messages. This paper presents a transformation method developed by the Swedish Transporters EDI Association in the Pharos XML/EDI project. 

Pharos Transformation Method starts from an existing Edifact implementation guide (MIG) where all  information necessary for a certain business transaction is defined. All specific Edifact syntax elements are removed and the basic operational data terms are structured into a so called Business Model, understandable for people, without any syntax knowledge needed.  

Next step is to formalize the Business Model into a so called UML model. UML is a modelling language with widespread use in the XML area, and  is also recommended by UN CEFACT as a tool for message development. 

One of the great advantages with using UML is that software is available to make it possible to automate the third and final step to an XML message. It has been proven feasible during the Pharos project to automaticly generate an XML/DTD as well as the corresponding XML Schema.  

Pharos Transformation Method has been developed in close connection with other relevant projects, above all CEN/ISSS  XML/EDI European Pilot Projects (Healthcare and Transport). High attention has also been given to the global ebXML initiative and other standardisation activities. 

References are given in the document to  transformation approaches tested in other projects, with  comments on their advantages and disadvantages.
 
1.2	  Conclusions 
•	The method has been tested and found very easy and straightforward to handle.
•	The transformation method is reusable by means of a set of principles and rules.
•	Standardized  rules for naming of business elements are highly important.
•	Tests have been performed on an EDIFACT message for Transport Booking. There should be no difficulties to use it in any other message area. 
•	Using UML has proved feasible with a reasonable amount of  resources.
•	The transformation can be partly automated. The degree of automation increases with number of transformed messages.

1.3	Further Work
•	Test the methodology on other UN/EDIFACT message types.
•	Adjust the methodology with recommendations from the ebXML project
•	Improve the XML generator software  with functions for message layout forms
•	Develop transport domain model “as global as possible”.

2.	 Introduction
2.1	 Background on Pharos project
The Swedish Transporters EDI Association has published Edifact Message Implementation Guides (MIG:s) since 1990 under the name of  Pharos.  They cover relevant scenarios within Transport and Logisitic, like booking, instructions, track and trace, and freight invoice.
During 1999 – 2000 a new project, called Pharos Internet, has been  carried out with a major  task  to find  the best way to migrate the Pharos messages from Edifact syntax to XML format.  The result is a recommendation of a transformation method in three steps, including use of  the Unified Modelling language, UML. 
This paper describes the Pharos Transformation Method. It  is one  part of  the final report from Pharos-Internet. Another part deals with methods for secure physical communication when using the open Internet for EDI. 

2.2	 Overview of  Pharos Transformation Method
The starting point for the transformation is a  MIG describing  a functional subset of a Edifact Message type. The way forward to an XML/DTD or an XML Schema consists of three steps, as illustrated in the picture below. 

Step 1.
The first step is a manually performed transformation of  the MIG to a so called  Business Model . This transformation intends to remove all specific EDIFACT syntax elements and extract a functional specification of the information contents and its structure. A person with  knowledge both of EDIFACT and the related business should perform this first step. 
See annex A for an example of a Business Model.

Step 2.
The second step transforms a Business Model to a UML Message Model. This step should be performed by a person with UML competence, and results in one or more formal conceptual models. The transformation is supported by a UML modelling tool, which can  produce documentation such as  class diagrams, class attribute lists, etc..
See annex B for examples of Message Model documentation. 

Step 3.
The third step will create the correspondent XML/DTD or XML Schema. For this step  the project group used a  software tool called Message Designer developed by SINTEF. It can be foreseen that similar software will be available on the open market to support the automated generation of XML messages from a formalized  UML model. 
See annex C and D for examples of  automated generated DTD and XML Schema.

Step 4 (optional).
The proposed transformation method also includes  an optional  fourth step with the possibility to store the elements of UML Message Models  in a Transport Domain Model for later reuse when new message types shall be developed. This is more discussed in chapter 2.5.

2.3	 Benefits and reasons  for Pharos Transformation method. 
•	All semantics in the Edifact message reflecting the relevant business transaction is reused.
•	Edifact syntax is removed making the message developing process easier to understand and maintain.
•	Existing Edifact structure (branch diagram) may be used as a starting point to build  a structure according to business needs. No formalities to change the structure when needed for better illustration of the business transaction.
•	References to Data Dictionary (mostly UN Codelist, but also other code sets) are kept as  necessary pointers to find the precise definition of each data term. 
•	Use of UML facilitates acceptance by both “XML world” and “traditional EDI world”.
•	Automatic generation of DTD and XML Schema.

2.4	 Summary of other approaches for transformations of EDIFACT to XML 

2.4.1	  Alt. A - Straight conversion Edifact to XML 1:1
Exact mirror of Edifact structure including name of segments, composites and data elements. See example below:
<!-- BGM : Beginning of Message -->

<!ELEMENT MessageId (#PCDATA) >
<!ATTLIST MessageId
	UN-EDIFACT:Segment	CDATA	 #FIXED	 "BGM" 
	UN-EDIFACT:Attributes	CDATA	 #FIXED	 "1001 MessageTypeCode 
					  1060 RevisionNo 
					  1225 MessageFunction
					  4343 ResponseType"
	 MessageTypeCode	CDATA	 #FIXED	 "BookingConfirmation"
	 RevisionNo	CDATA	 #IMPLIED
	 MessageFunction	(%Confirmation;)	 "Original"
	 ResponseType 	(%Response;)	 "Accepted"
	 Constraints 	CDATA 	#FIXED 	 "an..35" >

•	The method is easy to understand for Edifact people. 
•	Difficult to understand for non-Edifact people.
•	Needs knowledge both of Edifact and XML.
•	Does not utilize  any of the new  benefits in the XML format.
•	Brings on even the bad parts of Edifact.

For these reasons the method is not recommended by the Pharos project. The principle is however tested in CEN/ISSS European Pilot project, where also a DTD for a Transport Booking is created. See Reference List  A and B. 

2.4.2	  Alt. B -  Create XML DTD direct from Business model.
This was the  first approach in Pharos XML project. It was successful in the sense that it was very easy for an XML programmer to create a DTD based upon the information in the Business Model. 

Problems appeared however when the project group tried to standardize principles and rules. It turned out that the interpretation of the Business Model could be very subjective. Naming of elements and choices between element and attribute was very varying depending on the background of the XML programmer.

Conclusion:
A Pharos Business Model is a very good starting point for the creation of an XML DTD from an existing Edifact message (or MIG). But the componentes are hard to standardize. This led to the idea of using a formal UML Model to make it reusable by different programmers.

The bad expectations with using UML  were that it could be very time consuming. However  project experiences showed  that it took almost the same time to manually create a DTD compared to create a UML Message Model. And after that it was possible to get an automated generated DTD and/or XML Schema.

So the project group abandoned the simple method B, and instead elaborated the Pharos Transformation Method, as is described in this document.

2.4.3	  Alt. C - Creating XML DTD from a UML Domain model
In some newer Edifact message development groups, the standardization efforts have resulted in a UML Domain Model.  This is the case in Healthcare, where  CEN TC251 has developed  a  "Method for the development of Healthcare messages". The end result of this process is the production of a syntax independent UML representation of each message, referred to as a General Message Description (GMD). 

Such a model is probably one of the best starting points for creating messages of any syntax, Edifact as well as XML. In the CEN/ISSS European Pilot project mentioned above, a method is described how to map from such a domain model to XML DTD:s. The process turned out to be very succesful and included automatic creations of DTD:s. It is described in project deliverable, see Reference List C.

The same deliverable contains also a section with naming conventions when going from UML to XML, which has been found very valuable also in the Pharos Transformation Method.

In older Edifact message groups, like Trade, Transport and Customs mesages were not created  from any formal model. The Edifact structure itself was said to constitute also the business model. This is the case  in the Transport and Logistics area which is one reason for the Pharos Transformation Method.  While building UML models for one message at the time is a practical and feasible way, the ultimate goal should be to develop a general Transport UML Domain Model.

2.5	  Development of a Transport Domain Model

Most of the elements in UML Message Models may be used in multiple messages, and it should be unnecessary to perform multiple repetitions of the same transformation steps from EDIFACT MIG:s to UML Message Model. A possibility exists to store the Message Model elements in a separate Domain Model for later reuse. A Domain Model may in this way be stepwise developed based on the existing UN/EDIFACT standard definitions. 

Experiences with transformation of UN/EDIFACT messages to UML domain models have shown that  message contents corresponds strongest on the data element/attribute level. But the structuring of attributes in classes and associations are often different in a domain model compared to UN/EDIFACT segments and segment groups.

This implies that the structure of the domain model should exist on an early stage, in order to be used as a reference structure for the stepwise development of the bottom levels.

No standard domain model exists today for the transport sector. A number of European projects in the 4th framework program have developed data models for various aspects of freight transport, and one of the most comprehensive is TRIM- Transport Reference Information Model, see Reference List D.

Within  UN/Edifact the responibility for transport messages lies upon the EWG/D4 group, and  its ITIGG subgroup, (International Transport Implementation Guidelines Group). It should be an urgent  task  for D4 to elaborate a Transport Domain model.

2.6	 The issue of  XML tag names
One of the basic principles when implementing the XML language is to use human readable names (also called tags )  for XML elements in a message. The obvious advantage is that this makes it  easy to understand by programmers, leading to lower cost for software creation and maintenance. The obvious disadvantage is the increase of file size. An XML message is typically 3 – 5 times larger than correspondent Edifact message.

As an alternative principle it is proposed to use short tags, typically coded in the same way as an Edifact segment or element. This will give smaller file size, and it will also be more precise when it comes to an unambigous identification of a given element.

While Pharos Transformation Method is independent of the choice between the two naming principles, it could not be avoided to discuss the issue in the project. The group came to a consensus that ”human readable tags” are best for programmers and also  for traffic supervising. The ”Edifact-coded tags” are best for automatic mapping and also  best as key to dictionary definition. This led to a recommendation as follows: (See also Reference List F.)

•	Use human readable tag as element name
•	Use Edifact-coded tag as a required fixed attribute
•	Design XML mapping software to mandatory reading of  attributes 

3.	 Step 1 – From EDIFACT  MIG to Business Model 
3.1	 Illustration of a Pharos Business Model

Fig. 3-1.  A Business Model consists of sections, subsections and data terms
3.2	 Transformation from Edifact to Business Model 
Transformation rules may be varying in different  message development areas. For Transport messages based upon the IFTMIN structure following rules apply:  (BM = Business Model)
•	Edifact message structure (as shown in a branch diagram) should be taken as starting point.
•	Main segment groups on level 1 should correspond to  BM Sections.
•	Individual segments on consignment level have no relevant Edifact grouping. BM Sections should be created based upon business needs, from the view of operational understanding.
•	BM Subsections should be created based upon business needs, from the view of operational understanding. There is no mandatory demand for preserving structures like composite dataelements or hierarchical segments.  
•	BM DataTerms may originate from either a Edifact Data Element or a  code value for a certain DE.  In most cases it is necessary to include the code level to make a operational BM.
•	It should be noted that  when Edifact people refer to a ”code”  it includes a Tag,  a (sometimes rather long) Name,  and a definition of its meaning (Desc).  When using a BM DataTerm on code level  it refers to this whole ”code concept”.
•	A name of  a BM DataTerm should be specific enough to be understood. It is not enough with generic words as often used in  Edifact. 
•	Names should be as short as possible, considering information given by the context. It is not necessary to use the  full term name in the model as long as the model context offers full  unambigouty. 

3.3	  Additional principles and rules for Pharos Business Model (extract)
Full description to be found in Pharos deliverables. (Unfortunately only in Swedish so far). 
•	The BM should start with a one page verbal description of message scope, parties involved, limitations etc.
•	Information to be structured in  sections and subsections giving conditions and relations to other sections including hierarchy. 
•	Every data term used in the model may have following information items. They may be  mandatory (M) or optional (O) as marked below. 
Functional term name
(M)	Term name understandable by operational people involved in the business. “Parent name” may be omitted if clear from the context, e.g. by section headline.  	
Data type (O)	Representation class (as from BSR guidelines)	
Representation (O)	As in Edifact notation, e.g. an..35 or n6	
Condition: (M)	O = Optional, R = Required, D = Dependent.
When “D” a dependency note must be given 	
Standard Reference (M)	Standard sources may be: UNTDID, ISO, UN/ECE,  Itigg, etc. 	

•	The functional terms in the information model should be specific enough to be understood. It is not enough with generic words as often used in  Edifact. Example:  Consignment references (section C3) must also have each individual reference instance described as a specific line in the model. (1153-CT, 1153-AAS, 1153-CMR etc) 
•	While each term  in the Business Model  must  be found in a Data Dictionary, it is not necessary to use the  full term name in the model as long as the model context offers full  unambigouty.   E.g. ”earliest pickup” is enough in the model as the section heading says ”consignment date  and time” and  also the dataype column indicates Date/time.  (In a Data Dictionary  the term name would probably be  “consignment-earliest-pickup-date/time”.)
•	Term names used in the Business Model should be used in XML DTD or Schema as unchanged as possible still considering naming conventions like “Camel Case” etc. Example: “C2-1 Total gross weight” should be written “TotalGrossWeight”.  (In  a Term Catalogue the name would probably be  “Consignment-Total-GrossWeight-Value”)

As a result of the work it was found that in order to achieve a standardized implementation of  XML DTD:s or Schemas produced by independent persons it is necessary to document a set  of rules covering among others following issues:

•	Choice between  XML  element and  attribute
•	Naming conventions (”CamelCase”  was decided as the first recommendation)
•	Formatting rules  (an..17 n3 etc). Results from XML Datatyping Group is expected. 
•	Formalized way of making reference to a standard definition.

4.	 Step 2 – From Business Model to UML Message Model
4.1	 UML conceptual terms
An UML Message Model is a conceptual specification of a message type, and consists of:
•	Message classes
•	Attributes
•	Associations
These terms are defined in a formal UML glossary, (see Reference List E),  except “message class” which  is a subclass of a formal UML class.  This term is used to differentiate from ordinary UML classes (e.g. in a domain model), because a message class may contain attributes from one or more UML classes. 
Message classes are structured by associations in a hierarchical structure. A root message class must always be defined.
The Message Model is created in a suitable UML modelling tool,  the Pharos project group used “Rose 2000” from Rational and “Power Designer 7” from Sybase.  With the Business Model as starting point all data terms and sections were transformed and entered into the tool. The resulting output is Class diagrams, Class Atribute lists, etc. Examples see Annex.

A Business Model can be transformed to more than one Message Model, because a Business Model usually covers several message functions. A Business Model of a transport booking message may cover functions like: original request,  cancellation, replace, etc. Each function may result in a separate Message Model.

Fig 1. A Business Model may be transformed to one or more Message Models

4.2	 Naming Rules
The names in the Message Model should be in accordance with XML syntax. In practice, the most important rules to remember are:
•	Remove spaces in names. Example: “Goods Item” may be changed to: “GoodsItem”
•	Duplicate names are not allowed.

As mentioned above in a deliverable from  the CEN/ISSS European Pilot project, a method is described how to map from  a UML to XML DTD:s. The same document contains a set of  naming conventions, which have been found very valuable also in the Pharos project.
See Reference List C.

4.3	 The Message Root Class
Pharos Rule 1: 
Create the message root class with name equal to the message  name in the Business Model.

Fig. 2  Example of a message root class

The  message function as defined in the Business Model e.g. scope, definition, restrictions, etc. may be attached to the message root class.

4.4	 Transformation of Sections and Subsections
A sections or subsection in the Business Model  may be categorised in:
1.	Ordinary (sub) section 
A section or subsection that is not of category role list or value list.
2.	Role list
A (sub) section containing data terms that are role names. See  example below.
3.	Value list
A (sub) section containing data terms that specifies code values.
 See example in chapt 4.6. (subsection B1 “Basic service).

Role list example. 

A role name defines a task or duty of a class in an association with another class. The BM subsection “D1 Party functions” contains only data terms that are role names: Consignor, Despatch party, etc. for the section D  “Party”.
D2 is an ordinary BM subsection as defined above.

Pharos Rule 2:
Create a message class for each ordinary (sub) section.

The message class name is equal to the (sub) section name. 

(Sub) sections of the role list category will not result in message classes, but the role names will later be used to create associations.

(Sub) sections of value list category should not result in message classes, but will later be used to create attributes. However, the UML modeller has a choice to still create a message class containing one attribute.

There can be many sections and subsections in a Business Model, which may result in a lot of message classes. The modeller has the possibility to decide if some (sub) sections should be merged to common message classes. 

Pharos  Rule 3 (Optional):
(Sub) sections may be merged.
It is possible to merge (sub) sections which:
•	Have a maximum occurrence = 1  (are non-repeating), and
•	Have only one parent association. (are not multiple referenced)

The merging can be done between (sub)sections on the same hierarchical level, or child (sub) sections are merged with theirs parent (sub) sections.

4.5	 Associations

Pharos Rule 4:
Create single associations

Single associations are created from a parent message class to a child message class where the child message class is not multiple referenced.

Fig. 3  Example of a single association.

The associations in a message have only one direction, from parent to child. This association direction must have a muliplicity.

The multiplicity symbol contains a specification of minimum and maximum occurrences of the child message class, and is written as:
Minimum..Maximum
The multiplicity symbol is located at the child end of the association. The multiplicity values are taken from the (sub)section descriptions in the Business Model.

The diamond symbol at the parent end is an aggregation indicator, and specifies that the parent message class is an aggregate. The diamond symbol is optional and not needed for XML/DTD or XML Schema generation.

The example association in the figure above can be read as:

A TransportBooking has minimum 0 and maximum 9 Equipment.

Pharos Rule 5: Create multiple associations

Multiple associations are created for message classes that include subsections of the role list category.  

Fig. 4  Example of multiple associations.

Each of the multiple associations is given a multiplicity and a role name. The role names are found as data terms names in subsections of the role list category,  see 2.2.3.

The rolename is used in the generated XML/DTD or XML Schema as a “group” name for the attributes in the child message class structure. The UML notation uses a “+” before the rolename to indicate that the rolename is “public”, but this symbol will be stripped of in the generated XML/DTD or XML Schema.

The example multiple association in the figure can be read as:

A Consignment has minimum 1 and maximum 1  Consignor
A Consignment has minimum 0 and maximum 1  DespatchParty

4.6	 Attributes
The data terms in (sub) sections can be categorised in:
1.	Ordinary data terms
2.	Rolenames
3.	Code values

Examples of ordinary data terms are PartyName, PlaceOfDeparture, EarliestPickupTime, etc. 

Data terms of category rolenames have been treated above, and will not result in corresponding attributes.

	Functional term name	O/R/D	   Comments	Standard ref
B1 	Basic service	DE 4065
B1-1 Groupage	D	an..3		CL 7273 - 3
B1-2 Full load 	D	an..3		CL 7273 - 2
B1-3 Parcel transport	D	an..3		CL 4065 – 7

Example of Code Values.

Code values are data terms that represent a value in a value list. Examples of code values are presented below for the subsection Basic service.

The code value “Groupage” has the value “3”, “Full load” has the value “2”, and “Parcel transport” has the value “7”.

Pharos Rule 6:
Create attributes from ordinary data terms and code values.

An attribute is created for each ordinary data terms, and located in the message class corresponding to the attributes (sub) section.

A subsection that contains code values should be transformed to one attribute, which has allowed values according to the code list. 

Fig. 5. Example of a message class with attributes.

4.7	 Attribute Properties
When an attribute is created, a number of properties may be specified based on information from the Business Model:
•	Data Type
•	Multiplicity
•	Allowed values
•	Business rules
•	Comment
•	Standard reference 

The way of specification of these attribute properties may vary between the UML tools. Some tools  can support all of these properties, while others have a limited support. 

The data type is used in XML Schema generation, and must have an allowed value according to the XML Schema definition. Examples of the most common data types:
•	String35 – Alphanumeric character string of length 35
•	Int5 – Numeric character string of length 5
•	Date – Date and time

Multiplicity is used both for XML/DTD and XML Schema generation. Two values are allowed:
0..1    - Means an optional attribute
1..1    - Means a mandatory attribute

Allowed values are used to specify one or more allowed code values for the attribute. Examples:
OwnerIndication	“1” means Shipper,  “2” means Carrier
EquipmentType	”CN” means Container, “RR” means Rail Car, etc.

Allowed values are used for both XML/DTD and XML Schema generation. 

Business rules may be specified for some of the more complicated dependency notes in the Business Model. However, business rules are not used for XML/DTD or XML Schema generation. They may be specified for documentation purposes, and are needed in programs that logically controls XML message instances before storing in a database.

Comments about data terms in the Business Model may be copied as attribute comments. They are only used for documentation purposes.

Standard reference is a unique identifier that points to a standard attribute definition, e.g. an UN/EDIFACT data element tag number. The standard reference may be used for documentation purposes, and may also be used in the generated XML/DTD and XML Schema as an alternative to the attribute name. 

5.	 Step 3 - From UML Message Model to XML/DTD or XML Schema

5.1	 Automatic generation
The transformation process from UML to XML follows a formal algorithm, and can be performed mainly by a tool. Examples of XML/DTD and XML Schema generated by the MessageDesigner tool are found in Annex.

5.2	 Transformation rules
The transformation of a UML Message Model to XML/DTD or XML Schema is performed according to the following rules:

Message Model 	XML/DTD 	XML Schema	
Root message class name	Root element name	Root element type name	
Rolename	Element name	Element type name	
Association multiplicity	?, * , +, (empty)	Min and max occurrence	
Attribute name	Element name	Element type name	
Attribute data type	Not used	Date type and max length	
Attribute multiplicity	?, (empty)	Min and max occurence	
Attribute values	Allowed value list	Allowed value list	

Mapping between UML Message Model and XML/DTD and XML Schema.

5.3	 Sequence
The Business Model specifies a sequence of sections, subsections and data terms that should be kept in the Message Model. The associations and attributes should be modelled in the same sequence. This is possible for attributes, but not for associations. UML has no means to specify sequence of associations. In order to generate a XML/DTD or XML Schema with correct sequence of attribute names and role names, the generating tool should have a function for manually adjusting the sequence of role names for parent message classes. 

6.	 Reference List
A.	CEN/ISSS XML/EDI European Pilot deliverables 
D1:   XML Document Type Definitions for selected messages
         http://www.tieke.fi/isis-xmledi/D1/D1.htm
B.	Rules for mapping existing Edifact MIG:s to XML DTD:s
(draft working material from ISIS project group, available at Pharos website) 
         http://www.edifact-transport.se/library/engbib.html
C.	Mapping from UML Message Model to XML DTD
( Part of  CEN/ISSS European Pilot deliverable D9, available at Pharos website)
        http://www.edifact-transport.se/library/engbib.html
D.	TRIM- Transport Reference Information Model
        http://noemie.informatics.sintef.no/trim
E.	UML Notation Guide, version 1.1
        http://www.rational.com
F.	The issue of XML Tag names.Report from Pharos project.
http://www.edifact-transport.se/library/engbib.html

7.	  Annexes.
This report may be downloaded from www.Pharos.NU , select English library.
Direct URL: http://www.edifact-transport.se/library/engbib.html
File name: PHAROS_XML_EDI.ZIP 

All annexes are included as separat files, depending on different file formats. 
Individual file name for a certain annex is given below:
7.1	  Annex A – Example of a Business Model
Pharos Business Model.doc
7.2	  Annex B – Example of a UML Message Model
Class Diagram: Pharos UML digram.ppt
Class Attribute list: Pharos UML attributes.pdf
7.3	  Annex C – Example of a XML/DTD
Pharos booking.dtd
7.4	 Annex D – Example of a XML Schema
Pharos BookingSchema.xml
7.5	 Annex E – Example of a XML message instance
Pharos booking.xml