Home > Transformation of EDIFACT XML via UML

Transformation of EDIFACT XML via UML


      Transformation from Edifact to XML





Pharos XML/EDI Project

Transformation  from  EDIFACT  to  XML 

Version 1.03



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.   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.   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. 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��.


  1.   Introduction
    1.   Background on Pharos project

The Swedish Transporters EDI Association has published Edifact Message Implementation Guides (MIG:s) since 1990 under the name of  Pharos1.  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.


    1.   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 2. 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 Mmodel. 

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 and results in two documents, a cClass diagrams, and a class aAttribute lists, etc.
See annex B for examples of Message Model documentation. those two lists 

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 also an optional  fourth step with the possibility to store the elements of UML Message Models Types in a Transport Domain Model for later reuse when new message types shall be developed. This is more discussed in chapter 2.5.


    1.   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.


    1.   Summary of other approaches for transformations of EDIFACT to XML



      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: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.


      1.   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.



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.


      1.   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.


    1.   Development of a Transport Domain Model

Most of the elements in UML Message ModelsClasses 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 elementsClasses 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.


    1.   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



  1.   Step 1 - From EDIFACT  MIG to Business Model
    1.   Illustration of a Pharos Business Model


Fig. 3-1.  A Business Model consists of sections, subsections and data terms

    1.   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.


    1.   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 
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 Modelinformation 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 Minformation 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.


  1.   Step 2 - From Business Model to UML Message Model
    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 Pharos 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 SCybase (?).  With the Business Mmodel as starting point all data terms and sections were transformed and entered into the tool. The resulting output is a Class diagrams, and a 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



    1.   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.


    1.   The Message Root Class

Pharos Rule 1:

Create the message root class with name equal to the message  name in the Business Mmodel.


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.


    1.   Transformation of Sections and Subsections

A sections or subsection in the Bbusiness Mmodel  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 valuecode 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.


    1.   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:


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 correspond to (sub) sections 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, corresponding to the child message class, 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



    1.   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 subsectiongroup 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.



    1.   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 have 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. They can also be used for XML/DTD generation, which results in a slightly different message definition.


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 areis 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.


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


    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.


    1. 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 ElementElement name ElementElement type name
Attribute data type Not used Date type and max length
Attribute multiplicity ?, (empty) Min and max occurenceMin and max occurrence
Attribute values Allowed value list Allowed value list

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


    1.   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.



  1.   Reference List
  1. CEN/ISSS XML/EDI European Pilot deliverables  
    D1:   XML Document Type Definitions for selected messages 
  2. Rules for mapping existing Edifact MIG:s to XML DTD:s 
    (draft working material from ISIS project group, available at Pharos website)  
  3. Mapping from UML Message Model to XML DTD 
    ( Part of  CEN/ISSS European Pilot deliverable D9, available at Pharos website) 
  4. TRIM- Transport Reference Information Model 
  5. UML Notation Guide, version 1.1 
  6. The issue of XML Tag names.Report from Pharos project. 


  1.   Annexes.

This report may be downloaded from www.Pharos.NU , select English library.

Direct URL: http://www.edifact-transport.se/library/engbib.html



All annexes are included as separat files, depending on different file formats.  
Individual file name for a certain annex is given below:

    1.   Annex A - Example of a Business Model

Pharos Business Model.doc

    1.   Annex B - Example of a UML Message Model

Class Diagram: Pharos UML digram.ppt

Class Attribute list: Pharos UML attributes.pdf

    1.   Annex C - Example of a XML/DTD

Pharos booking.dtd

    1.   Annex D - Example of a XML Schema

Pharos BookingSchema.xml

    1.   Annex E - Example of a XML message instance

Pharos booking.xml

      Pharos XML/EDI project 2000-03-20

1 Pharos was the name of the antique lighthouse outside Alexandria built to support the international sea transport. It is recognized as one of  the seven wonders of the world.

2 The term Business Model is used by Pharos to separate it from an Edifact message model or an UML model. While these other two have strong formal restrictions, the word Business Model indicates that focus is concentrated upon the information contents used by business people for operational purpose.

Search more related documents:Transformation of EDIFACT XML via UML

Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#nuokui.com