ISD Interface Specification Document - FF
|[pic] |EUROPEAN COMMISSION |
| |DIRECTORATE-GENERAL XIV |
| |FISHERIES |
| |Horizontal measures and markets |
| |Databases and fisheries economics |
FIDES II
INTERFACE SPECIFICATION
DOCUMENT
FILE FORMAT
|Project: |FIDES II |
|Part: |System Specification phase |
|Title: |FIDES II – Interface Specification Document – File Format |
|Date: |DECEMBER 1999February 2000 |
|Author: |J. HESHMATI(Dixite) - R. DEMO(Dixite) – A. VAN MUYSEWINKEL(Dixite) |
|Notes: | |
|Folder: | |
|Distribution: | A3-Inf, FIDES Work Group, System Supplier - for comments |
|PROJECT IDENTIFICATION |
|Contract number |Programme |WBS number |
|502007.1 | | |
|Client |Contractual |Lot |
|CEC DG XIVDG FISH | | |
| |Name, function |Date |Signature |
|Prepared by : |Javad HESHMATI (Dixite) | | |
| |Arnauld VAN MUYSEWINKEL (Dixite) | | |
|Verified by : |Rudy DEMO (Dixite) | | |
|Quality control : |Pascal DESART (Amsit) | | |
|Approved by : |Nelson Jorge (IconMedialab) | | |
|Authorised by : |DG XIVDG FISH Project Manager (DG XIVDG FISH) | | |
|Summary : |Keywords : |
|This document defines the detailed design of the FIDES II project |ISD, fides II, design, detailed|
|DOCUMENT IDENTIFICATION |
|Number of pages |Copy ID |Linked documents |System |
|53 | | |PC |
|Number of pictures | | |Software |
|22 | | |Microsoft Word 97 |
|Archiving number | | |Template |
|5 | | | |
Modifications
| | | | |
|Revision |Date |Modified paragraphs |Modifications |
| | | | |
|00.00 EN 01 |03-JUN-99 |Document creation |--- |
| | | |DGXIVDG FISH Quality Control Revision |
|00.00 EN 02 |22-JUN-99 |All | |
| | |Changed 4, 5 | |
|00.00 EN 03 |02-JUL-99 |Removed 6 |Change the specification |
| | | |Dixite and DG XIVDG FISH final review. |
|00.00 EN 04 |07-SEP-99 |All | |
| | | | |
|00.00 EN 05 |10-SEP-99 |All |Dixite corrections |
| | | | |
|00.00 EN 06 |14-OCT-99 |All |FOH comments, CR009 reference addition, |
| | | | |
|00.001 EN 007 |23-DEC-99 |All |Change requests and header parameters |
| | | | |
|00.00 EN 08 |10-JAN-2000 |All |Dixite Internal review |
| | | | |
|00.00 EN 09 |11-JAN-2000 |All |Consortium Quality Control |
| | | | |
|00.01 EN 00 |19-JAN-2000 |All |DG Fish Review and Dixite Minor modifications |
| | | | |
|00.01 EN 01 |24-JAN-2000 |All |Changed decision tree for *.FORMAT parameters |
|00.01 EN 01 |03-FEB-2000 |All |FOH comments 01/02/2000 |
Table of Contents
1. Document 6
1.1. Document objectives 6
1.2. Application field 6
1.2.1. Concerned products 6
1.2.2. Modalities 6
1.3. Responsibility 6
1.3.1. Writing responsibility 6
1.3.2. Approval and authorisation responsibility 7
1.3.3. Updates 7
1.4. Applicable documents 7
1.5. Reference documents 7
1.6. Technical bibliography 9
1.7. Technical URL’s 9
2. Introduction 10
2.1. FIDES History 10
2.2. System Purpose 10
2.3. Project Organisation 10
3. Definitions, Acronyms and Abbreviations 12
3.1. Definitions 12
3.2. Abbreviations 13
4. Conversion services 15
4.1. Line Separator conversion 15
4.2. Character set conversion 16
4.3. Body presentation conversion 16
4.4. Services behaviour 17
4.4.1. Services attributes 17
4.4.2. Attributes types 17
4.4.3. Example 17
5. Body Presentation Conversion 19
5.1. Introduction 19
5.2. Postulates 19
5.3. Introduction to body format 21
5.4. EBNF : Common definitions 22
5.5. Fides I message : EBNF description 22
5.6. Fides II message : EBNF description 23
5.7. Body format structure : EBNF description 23
5.8. Fides II Header Parameters 24
5.8.1. Definition 24
5.8.2. Cardinality 26
5.8.3. Legend 27
5.8.4. EBNF 27
5.8.5. Decision tree for default values 28
5.8.6. Fides II header parameters : conversion considerations 30
5.8.6.1. Fides II header parameters converted from Fides I data 30
5.8.7. Fides II Additional Parameters : conversion considerations 30
5.8.7.1. Additional parameters : converted from Fides I e-mail subject 30
5.8.7.2. Fides II header parameters converted from file names 31
5.8.7.3. Additional parameters from external parameter file 31
5.8.7.4. Additional parameters from transaction dynamic arguments 31
5.9. Body : parsing considerations and default values 32
5.10. Fields constraints 33
6. Examples 34
7. Remarks 36
7.1. File format 36
7.2. Business Process Bridges 36
8. ANNEXES 38
8.1. Annex A : Administrations involved 38
8.2. Annex B : Extended Backus-Naur Form (EBNF) notation 39
8.3. Annex C : Country codes 40
8.4. Annex D : Old Header Parameters Name mapping 44
8.5. Annex E : PL-SQL parser sample code 45
8.6. Annex F : Perl parser sample code 47
8.7. Annex G : Character-sets 49
8.7.1. Names 49
8.7.2. Unicode encoding 51
8.8. Annex H : Presentation Types 53
List of Tables
Table 1: DG FISH involvement in FIDES II 11
Document
1 Document objectives
This document defines the Interface Specification of the FIDES II project.
This project is realised for the European Commission General Directorate XIVGeneral Directorate Fish by a Consortium composed of Icon Medialab (prime contractor), DIXITE S.A. and AMSIT S.A.
This document is divided into the following sections:
• section 1: describes document modalities.
• section 2: describes the document application fields.
• section 3: lists all the definitions and acronyms used within this document.
• section 4 : describes generalities about the overall context conversion services of this document
• section 5 : highlights details the general structure of the Fides II file format
• section 6 : details the constraints imposed on the Fides II file format
• section 76 : is an example of the file format conversion as realised by the parser
• section 8 7 : provides some remarks about Fides II file format processing
• section 9 8 : list the annexes of this document
This document conforms to the rules identified in [RD1] and [RD2].
2 Application field
1 Concerned products
All FIDES II components.
2 Modalities
The ISD is applicable from its delivery until the end of the project.
3 Responsibility
1 Writing responsibility
The Interface Specification Document is written under the responsibility of the Analysts.
The Consortium Project Manager verifies this document.
The Quality Manager performs the quality control for the ISD.
2 Approval and authorisation responsibility
The document is approved by the Consortium's Management. The Consortium is committed to respect the quality standards set out at the beginning of the project.
The document is authorised by DGXIVDG FISH FIDES II Project Manager.
3 Updates
The updates are performed under the responsibility of the Consortium Analyst. The verification is performed by the technical team, the quality control is the responsibility of the Quality Manager and the approval and authorisation are performed by the Consortium project manager.
Applicable document: a document whose content must be respected and implemented.
Reference document: a document where related information can be found.
4 Applicable documents
This table identifies the documents applicable to the FIDES II project:
|Ref. |Document Name |
|AD1 |FIDES II Contract between DG XIVDG FISH and the Prime Contractor |
|AD2 |The consortium proposal to Invitation to tender ITT number DG III/98/049 IDA-071.01/99/Fides – |
| |21/09/98 |
5 Reference documents
This table identifies the documents referenced in the FIDES II project:
|Ref. |Document Name |
|RD1 |FIDES II – Project Management Plan v3.0.2. – FIDES II-PMP-01 - 23/02/99 |
|RD2 |FIDES II – Project Quality Planv3.0.2. – FIDES II-PQP-01 - 23/02/99 |
|RD3 |IEEE Standards (for Software User Documentation, Guide to Software Design Descriptions, |
| |Recommended Practice for Software Design Descriptions) |
|RD4 |Interface Specifications v0.2 Draft – 27/01/1999 – DG XIVDG FISH |
|RD5 |Software Requirements Document – FIDES II-SRD-0200EN01 – Dixite – 29/03/99 |
|RD67 |Architecture Design Document – FIDES II-ADD-0001EN001 – Dixite – 1025/04/99 |
|RD7 |Minutes of the technical Meeting held on 10/11/1999 |
6 Technical bibliography
This table identifies the documents referenced in the FIDES II project:
|Ref. |Document Name |
|TR1BL1 |X.400 standard named "Message handling system and service” at [TU7] and [TU6] UML Summary – |
| |version 1.1 - 1 September 1997 – OMG |
7 Technical URL’s
|Ref. |Document Name |
|TU1 | |
|TU2 | |
|TU3 | |
|TU4 | |
|TU5 | |
| |Sun's Java site ("The Source for Java™ Technology") |
|TU6 | |
| |[F.400/X.400am1] Amendment 1 (09/98) to Recommendation F.400/X.400 - Message handling system and|
| |service overview Amendment 1 |
|TU7 | |
| |[X.400/F.400] Recommendation X.400/F.400 (07/96) - Message handling system and service |
|TU8 | |
| |Very good introduction to the world of character sets and Unicode. |
|TU9 | |
| |The official Unicode site. |
Introduction
FIDES, the Fisheries Data Exchange System is a general communications infrastructure linking the European Commission, DG XIVDG FISH, and administrations in the Member States. The project, originally based only upon the X.400 e-mail service has entered its second phase in which FIDES II will take full advantage of the Internet technology and support different data exchange technologies to the communication partners as alternative modes of transmission.
1 FIDES History
The system originated in a joint operation between DG III, responsible for the IDA programme and DG XIVDG FISH, responsible for the Common Fisheries Policy (CFP). FIDES has so far been entirely funded under the IDA Programme and is listed in Council Decision 468/95 of 6 November 1995 as the recognised sectoral project for fisheries. More information on this IDA project can be found on following URL :
2 System Purpose
The FIDES system aim is to improve execution of the Common Fishery Policy by automating data flows between ALL Fisheries administrations in Member States (and some non-EU countries) and the European Commission, using modern and cost efficient telematics services and applications.
The FIDES II should offer a service to the most commonly used data exchange technologies in such a way that the Communication Partners can use a familiar preferably commercially available technology in order to communicate with the Commission.
3 Project Organisation
The project is in principle funded by IDA; complementary funding from Informatics or more specific budget lines from DGXIVDG FISH may be envisaged if justified.
The Project Owner for the project is Mr.C.Vamvakas, Head of Unit Fish.1, Informatics.
The Project Manager is Mr.F.Olsson-Hector, working under the supervision of Mr.F.Dom - System Owner of FIDES II.
Mr.R.Natale, auxiliary of DGXIVDG FISH acts as System Manager and will monitor the implementation and installation of the final system from a technical point of view ; he will also execute certain developments on behalf of DG XIVDG FISH.
The System Supplier is a consortium formed by the following companies: Icon Medialab International, Amsit and Dixite companies.
The following table indicate the involvement of each person in the project.
|Person |Time |Remarks |
|Project Owner |1% |EDETF, Directors Committee |
|System Owner |20% |Definition of the specifications and evaluation of the |
| | |development process |
|Project Manager (official of the |50% |Follow-up of the project |
|concerned service)[1] | | |
|System Manager (official of the |100% |Follow-up of the project, small developments, tests, system |
|concerned service)[2] | |operation |
|System Supplier (person from the IRM|100% |During design, development, test and running-in. |
|team, A or B grade) | | |
|Development team |100% |Proposed way of working – budgetary aspects, if applicable |
Table 1: DGXIVDG FISH involvement in FIDES II
The Steering Committee for the project includes all members of the Electronic Data Exchange Task Force. The Correspondents outside DG XIVDG FISH are listed in annex at section 8.1.
The Steering Committee for the project will meet each month to discuss the status report as presented by the System Supplier.
Definitions, Acronyms and Abbreviations
1 Definitions
• Message is a file containing all the necessary information in order to be treated by the FIDES II system. Each message is composed of two parts :
• Header, containing Fides II parameters;
• and Body containing data and additional information, used only by the business process.
• Transaction : is the suite of Fides II events and actions performed when processing is requested to Fides II. For example, when an information is queried, before and after transmitting information to the business process, Fides II triggers functions like character set conversion, message parsing, end of line conversion, etc.
• Fides II parameters : are necessary information for the savvy processing of the transaction by FIDES II. For example, the title of the transaction identifies the type of transaction, character set identifies the character set of the transaction, etc..
• Business Process : the business process is a functional unit allowing the treatment of a report. It is not part of FIDES II and is under the responsibility of the concerned DG Fish regime project management.
• Presentation : instantiation of an abstract body syntax. This abstract syntax is defined by the EBNF diagram in section 5.7. It is identified with a name following this syntax :
PresentationName = PresentationTypeName, [':', PresentationSetName];
(* if the presentation set is not specified, the set named 'default' will be used *)
• Presentation Set : identifies several possible abstract syntax instatiationsinstantiations based on a set of information allowing to perform for a same body structure different presentation conversions. Each set enables to define 13 different types of presentation (see below).
• Presentation Type : is the identifier of a presentation. It is represented by :
PresentationTypeName = (RecordPresentationName, '-', FieldPresentationName) | "HtmlFlow"
RecordPresentation = "StartTagEndTag" | "StartTagTerminator" | "Terminator"
FieldPresentation = "StartTagEndTag" | "StartTagTerminator" | "Terminator" | "FixedSize"
• Transaction Type : the type of a Fides II transaction is Fides II can be of four types :
• Query : the business process executed will perform a query on a DG Fish data store. The information retrieve is related to DG Fish operational information.
• Report : the business process executed will perform the insertion of information contained in the Fides II message transmitted into a DG Fish data store.
• Statistics : the business process executed will perform a query on Fides II database logs.
• Help : transaction used to retrieve assistance information,
TransactionTypeName = "QUERY" | "REPORT" | "STATISTICS" | "HELP"
• Request : an incoming transaction is called a “request” in Fides II;
• Reply : an outgoing transaction is called a “reply” in Fides II;
• Body Format : is the higher level abstract element describing Fides II message bodies. It is composed of :
• Structure (# = 1): lists the elements composing the body structure as well as their hierarchical organisation. For example, the record DAT is composed of fields SPECIESCODE, AREACODE, etc.
• Presentation set (# = 0..*): is defined above.
• Constraints set (# = 0..*): is a set of conditions that must be matched by fields. In case a constraint is not matched, an exception is thrown during the parsing.
• N/AUser parameters : are a set of user related information giving Fides II the necessary elements to process transaction requests. The Fides II parameters can be grouped into the following families :
• User ID Card : is the set of information describing the end-user. For example, name, surname, citizenship, etc.
• User Preferences : is the set of information defined by the end-user in order to states his/her preferences for date format, real format, language, etc.
• User Access Rights : is the set of information allowing to describe the Fides II privileges granted to a particular user.
• Additional Parameters : when the end-users wants to overload his/her parameters or overloads message header parameters, he/she can provide information additional parameters. It is an information external to the transaction. See section 5.8.7 for more detailed information.
2 Abbreviations
|Abbreviation |Description |
|ADD |Architectural Design Document |
|AD |Architectural Design |
|AR |Alternate Recipient |
|BP |Business Process |
|BPB |Business Process Bridge |
|CDD |Code Documentation Document |
|CEC |Commission of the European Community |
|DDD |Detailed Design Document. |
|DG |Direction Générale (Eng. General Directorate) |
|DN |Delivery Note |
|DT |Data Transmission |
|DTB |Data Transmission Bridge |
|EBNF |Extended Backus-Naur Form |
|FIDES |Fisheries Data Exchange System |
|FIDES I |FIDES System based upon X.400 e-mail |
|FIDES II |Current project opening FIDES towards other technologies |
|F2ADM |FIDES II Administration tool |
|F2DEM |FIDES II Data Exchange Monitor. We use the term Kernel in this document. |
|F2MON |FIDES II Monitoring Component |
|HTML |HyperText Markup Language |
|HTTP |HyperText Transfer Protocol |
|ID |Identifier |
|IDA |Interchange of Data between Administration |
|ISD |Interface Specification Document |
|N/A |Not Applicable |
|OS |Operating System |
|PM |Project Manager |
|QM |Quality Manager |
|RD |Reference Document |
|RDBMS |Relational DataBase Management System |
|RMI |Remote Method Invocation |
|SAD |System Administration Document |
|SRD |Software Requirements Document |
|UML |Unified Modelling Language |
|USMAN |User Manual |
|VAS |Value Added Services |
File Interface - File Format Conversion services
This document describes the File Interface implemented in Fides II.
The following section is a service explanation to provide to the Business Process developers the complete picture of all the conversions that are realised on a Fides II file by Fides.
1 Line Separator conversion
Here is how line separator conversion works in Fides II :
1. Whenever a transaction enters the system from an end-user, any type of line separator is converted to an internal representation of line separator.
2. The LineSeparatorConversion service modifies the value of the 'CONTENT_TYPE.CURRENT.LINE_SEPARATOR' transaction parameter according to the transaction configuration in LDAP. (i.e. EUROASCII).
3. When the transaction exits the system to the Business Process, Fides generates line separators as specified by the 'CONTENT_TYPE.CURRENT.LINE_SEPARATOR' transaction parameter.
4. When the transaction enters the system from the Business Process, any type of line separator is converted to an internal representation of line separator.
5. The LineSeparatorConversion service modifies the value of the 'CONTENT_TYPE.CURRENT.LINE_SEPARATOR' transaction parameter according to the decision tree specified in section 5.8.5 (i.e. user value of CONTENT_TYPE.REPLY.LINE_SEPARATOR defined in message).
6. When the transaction exits the system to the end-user, Fides generates the line separators as specified by the 'CONTENT_TYPE.CURRENT.LINE_SEPARATOR' transaction parameter.
Here are the supported line separators:
- LF = #x0A (* e.g. : Unix™-like systems *)
- CR = #x0D (* e.g. : Apple systems *)
- CRLF = #x0A, #x0D (* e.g. : PC-compatible systems *)
2 Character set conversion
Here is how character set conversion works in Fides II:
1. Whenever a transaction transmitted from an end-user enters the system, it is converted from its native character (see decision tree in section 5.8.5 for character set default value) set to Unicode.
2. The incoming CharacterSetConversion service modifies the value of the 'CONTENT_TYPE.CURRENT.CHARACTER_SET' transaction parameter according to the transaction configuration in LDAP.
3. When the transaction exits the system, it is converted from Unicode to the character set specified by the 'CONTENT_TYPE.CURRENT.CHARACTER_SET' transaction parameter.
4. When the transaction transmitted from the business process enters the system, it is converted from the character set specified in CONTENT_TYPE.CURRENT.CHARACTER_SET to Unicode.
5. The outgoing CharacterSetConversion service modifies the value of the 'CONTENT_TYPE.CURRENT.CHARACTER_SET' transaction parameter with :
• CONTENT_TYPE.REPLY.CHARACTER_SET, if defined;
• same as the additional parameter CONTENT_TYPE.CURRENT.CHARACTER_SET, if defined;
• extracted from user preferences, if defined;
• Fides default (i.e. Cp1252) character set.
6. When the transaction exits the system, it is converted from Unicode to the character set specified by the 'CONTENT_TYPE.CURRENT.CHARACTER_SET' transaction parameter.
The list of supported character sets is specified in section 8.7.
3 Body presentation conversion
This is actually realised by 3 services :
1. Parsing : reads the body according to the current presentation and generates an internal structured representation of the data
2. Constraints checking : checks the constraints in the internal structured data
3. Body Presentation Conversion : generates a new presentation of the body from the internal structured data
The Body Presentation Conversion service itself is described in section 5 onwards.
4 Services behaviour
This sub-section is used to provide basic information on the service configuration.
For each transaction can be configured zero, one or more services. Is mentioned below the information used by the service in order to perform properly its processing.
1 Services attributes
Each service mntioned above is using as input parameter :
• Parsing service : inPresentationName
• ConstraintsChecking service : constraintsSetName
• PresentationConversion service : outPresentationName
• CharacterSetConversion service : outCharacterSetName
• LineSeparatorConversion service : outLineSeparatorName
2 Attributes types
The attributes mentioned above can be of two types :
• static : a string;
• dynamic : the name of a transaction parameter from which the attribute value will be fetched by the service, at execution time.
This flexibility is important as it provides the possibility to define configuration values that are based on parameter values and therefore variable
3 Example
These examples illustrate some typical cases of services configuration where the services values are configured with static and dynamic arguments.
Request :
• Parsing service : inPresentationName = Dynamic("CONTENT_TYPE.CURRENT.PRESENTATION")
• ConstraintsChecking service : constraintsSetName = Static("Set1")
• PresentationConversion service = outPresentationName = Static("StartTagEndTag-StartTagEndTag")
• CharacterSetConversion : outCharacterSetName = Static("EUROASCII")
• LineSeparatorConversion : outLineSeparator = Static("CRLF")
Reply :
• Parsing service : inPresentationName = Dynamic("CONTENT_TYPE.CURRENT.PRESENTATION")
or Static("StartTagEndTag-StartTagEndTag") [3]
• ConstraintsChecking service : constraintsSetName = Static("SetA")
• PresentationConversion service = outPresentationName = Dynamic("CONTENT_TYPE.REPLY.PRESENTATION")
• CharacterSetConversion : outCharacterSetName = Dynamic("CONTENT_TYPE.REPLY.CHARACTER_SET")
• LineSeparatorConversion : outLineSeparator = Dynamic("CONTENT_TYPE.REPLY.LINE_SEPARATOR")
Body Presentation Conversion
1 Introduction
The following is the Fides document formatting history : In terms of FIDES document formatting, the following steps have been covered throughout the version of FIDES :
• FIDES I version 1 described formats based on fixed length records and EDIFACT data structure;
• Next releases of FIDES I, EDIFACT technology was dropped and a number of different reports based on CSV format were defined;
• During the analysis of FIDES II, DG XIVDG FISH asked Dixite to evaluate the possibility to achieve a certain flexibility in the report formatting (different separators and different presentations possibility);
• DG XIVDG FISH asked Dixite to evaluate the possibility to re-structure a report like transforming multiple single field records into one multiple field records. Within this request in mind and the fact that XML emerged like a new standard in term of data structure, Dixite has made a proposal for using XML. This idea has not been retained.
• Thise final version 00.00EN06 of the document is the result of the technical meeting of 04/09/1999 with DG XIVDG FISH.
• The version 00.00EN06 of the document is the result of the technical meeting of 11/10/1999 with DG FISH and the change requests CR005 and CR015.
This document has the scope of defining the interface between:
• FIDES II and external components, in general;
• and the business processes and FIDES II, in particular.
Another document called “Interface Specifications Document – Java Interface” will defined the interface to be implemented into by new components bridges in order to be integrated within the Fides II architecture.
The following postulates have been considered and confirmed with DG XIVDG FISH :
• the interface between BP and FIDES II is a message as described in the following sections.
• All Fisheries data exchange between MS/Correspondents and the Commission should be done via those predefined messages.
• Additional parameter can be added to the predefined messages. It is considered that an additional parameter always overload the same parameter that might be defined in the message itself.
2 Postulates
• A message should be sent as one flat file and must be as much as possible "self-sufficient" (in Fides II parameters) in order to be processed by FIDES II. Additional parameter can be added to the message. It is considered that an additional parameter always overload the same parameter defined in the message.
• All messages should follow a common structure with a header part (containing Fides II parameters) and a body part (containing data).
• FIDES II is not modifying data[4]. For example "TTT;RRR" can be converted in "TTT|RRR" as this is not to be considered a data modification. "TTT" and "RRR" is the data.
• FIDES II file formats should as much as possible support the FIDES I messages formats. The following remarks have been raised by the Consortium and agreed by DG FISH (extract of RD7) :
• "Fides I Alternate recipient records identified by the following tags , , will be migrated to the Fides II header and become valid Fides II AR records;
• All records in a body are all of the type named (tagged) or ordered records but not a mix of both. This will imply that for FR-REPLY, FR-ACK-XIV, LI-REPLY the message defined is made of a mix of named and ordered records. In a Fides II message, the body to be generated by the Business Process must be presented in a particular order without tags or with tags for all records[5];
• Comments on a file should be realised through the same record type as in the rest of the body (named (i.e.: [6]xxxxxx) or ordered). So having strings like '# this is my comment' in the middle of a tagged body is not anymore valid;
• for all market reports (identified by 2210xxx and 2211), the last field of the record should end with a ';'.
• CR-LANDING, the period record X(8) TO X(8) can be checked against date constraints only if the record is considered to be composed of three fields date, string and date.
• Optional*[7] means in fides I that a least one of the field qualified as OPTIONAL* must be present in the file. In a Fides II message, we have only optional and mandatory fields; "[8]
• Each body format is composed of :
• one body structure;
• one or more presentation sets;
• one or more field constraints.
• A message cannot contain more than one body. There might exist formatting differences between the end-user message and the message required by the business process. In this case, a conversion between two presentations must occur so that the end-user message is converted into the expected BP message. The two presentations can be defined in the same presentation set or not. In case not, the end-user will have to specify the name of the presentation set he wants to use, otherwise the default presentation set is used.
• FIDES II does not make differences between a query and a report.
• Within FIDES II, all processed messages are in clear text. If encryption/decryption operations occur on the message flow, they are done outside the scope of the FIDES II application.
3 Introduction to body format
A message, whether sent or received should contain a header and a data body part. Here is an example of such FIDES II message structure:
… Fides II parameters …
… data …
For example, this structure can be translated by the following type of message:
|Example |Structure description |
| | |
| | |
|c |Fides II Parameter |
|d |Fides II Parameter |
|e |Fides II Parameter |
| | |
| | |
|0000 |FieldValue |
|Maria |FieldValue |
|d;f;g;h;h; |FieldValue;FieldValue;FieldValue; |
| | |
| | |
In this example, we have two single-field records ('0000', 'Maria') and one multi-fields record ('d;f;g;h;h;'). It is obvious that fFor each file body, several modelling presentation possibilities exist. The “File Format Manager”administrator must understand the data model before defining a FIDES II file body format.
NOT SURE??? Why don’t we have an OPTIONAL_BLANK after value content for the fixedsizefield. Because it has {SPACE}? How will the parser know that ‘__1__2_____4’ means the field values (1,2, null, 4). Will it not consider the 4 as the third field? Is the length of the field helping? Would it be easier to consider having only 1 optional blank after the field???
4 EBNF : Fides I message : EBNF descriptionCommon definitions
DOUBLEQUOTE = #x22; (* '"' *)
SPACE = #x20; (* ' ' *)
LF = #x0A;
CR = #x0D;
CRLF = CR, LF;
EOL = LF | CR | CRLF;
TAB = #x09;
COLON = #x3A; (* ':' *)
SEMICOLON = #x3B; (* ';' *)
PIPE = #x7C; (* '|' *)
SLASH = #x2F; (* '/' *)
BACKSLASH = #x5C; (* '\' *)
DOT = #x2E; (* '.' *)
COMMA = #x2C; (* ',' *)
OPTIONAL_BLANK = {SPACE | TAB | EOL};
LT = #x3C; (* '' *)
UNDERSCORE = #x5F; (* '_' *)
MINUS = #x2D; (* '-' *)
Terminator = TAB | COLON | SEMICOLON | PIPE | SLASH | EOL;
FirstTagChar = LT;
LastTagChar = GT;
EndTagChar = SLASH;
StartTag = OPTIONAL_BLANK, FirstTagChar, Name, LastTagChar;
EndTag = FirstTagChar, EndTagChar, Name, LastTagChar, OPTIONAL_BLANK;
Name = {UpLetter | DecimalDigit | UNDERSCORE | MINUS | DOT}-;
Letter = UpLetter | LoLetter;
UpLetter = #x41 | ... | #x5A; (* 'A' | ... | 'Z'; *)
LoLetter = #x61 | ... | #x7A; (* 'a' | ... | 'z'; *)
DecimalDigit = #x30 | ... | #x39; (* '0' | ... | '9'; *)
HexLetter = #x41 | ... | #x46 | #x61 | ... | #x66; (* 'A' | ... | 'F' | 'a' | ... | 'f'; *)
HexDigit = DecimalDigit | HexLetter;
AsciiPrintableChar = #x20 | #x21 | ... | #x7D | #x7E; (* interpreted according to ISO 646-US *)
8BitChar = #x00 | #x21 | ... | #xFE | #xFF)
(* interpreted according to the character set defined *)
EscapeChar = BACKSLASH;
QuoteChar = DOUBLEQUOTE;
UnicodeEscapedChar = BACKSLASH, #x75, HexDigit, HexDigit, HexDigit, HexDigit;
(* '\uXXXX' Unicode Plane 0 (BMP) encoding *)
ReservedChar = Terminator | FirstTagChar | EscapeChar | QuoteChar;
AuthorizedChar = 8BitChar - ReservedChar;
Char = AuthorizedChar | UnicodeEscapedChar;
(* i.e. actually 1 or 6 bytes !,
but it always count for only 1 position (important for fixed size fields) *)
5 Fides I message : EBNF description
Message = {FideILine}-Header, [Body], OPTIONAL_BLANK ;
FidesILine = FidesIHeaderLine | FidesIBodyLine;
Header = OPTIONAL_BLANK, HeaderContent, OPTIONAL_BLANK;
HeaderContent = {FidesIIParameter};
FidesIIParameterHeaderLine = OPTIONAL_BLANK, FidesIIParameterStartTag, FidesIIParameterValue, EOL;
FidesIIParameterStartTag = FirstTagChar, FidesIParameterName, LastTagChar;
FidesIParameterName = 'TTL' | 'RMS' | 'ASM' | 'FAX' | 'AX4';
FidesIIParameterValue = {AsciiPrintableChar}
Body = OPTIONAL_BLANK, BodyContent ;
BodyContent = [RecordsSet];
RecordsSet = NamedRecords | OrderedRecords | MixedRecords;
MixedRecords = [NamedRecords], {NamedRecords | OrderedRecords};
NamedRecords = StartTagTerminatorRecords;
StartTagTerminatorRecords = {StartTag, RecordContent, Terminator}-;
OrderedRecords = CharTerminatedRecords
CharTerminatedRecords = {RecordContent, Terminator}-;
RecordContent = FieldsSet;
FieldsSet = NamedFields | OrderedFields
NamedFields = StartTagTerminatorFields;
StartTagTerminatorFields = {StartTag, FieldValue, Terminator}- , (StartTag, FieldValue, Terminator) | (StartTag, FieldValue);
OrderedFields = CharTerminatedFields | FixedSizeFields;
CharTerminatedFields = { FieldValue, Terminator}-;
FixedSizeFields = {BlankPaddedValue, OPTIONAL_BLANK }-;
FieldValue = ValueContent;
BlankPaddedValue = ValueContent, {SPACE};
ValueContent = {PrintableChar - '0 AND endTagIdx>bgnTagIdx) THEN -- there is a tag
tagName := SUBSTR(line, bgnTagIdx+1, endTagIdx-bgnTagIdx-1);
IF (tagName='FIDES II') THEN
IF (Fides IIContext>0 OR headerContext>0 OR bodyContext>0)
THEN ERROR(lineCount, bgnTagIdx, 'unexpected tag ');
ELSE Fides IIContext:=1; END IF;
ELSIF (tagName='/FIDES II') THEN
IF (Fides IIContext!=1 OR headerContext!=2 OR bodyContext=1)
THEN ERROR(lineCount, bgnTagIdx, 'unexpected tag ');
ELSE Fides IIContext:=2; END IF;
ELSIF (tagName='HEAD') THEN
IF (Fides IIContext!=1 OR headerContext>0 OR bodyContext>0)
THEN ERROR(lineCount, bgnTagIdx, 'unexpected tag ');
ELSE headerContext:=1; END IF;
ELSIF (tagName='/HEAD') THEN
IF (Fides IIContext!=1 OR headerContext!=1 OR bodyContext>0)
THEN ERROR(lineCount, bgnTagIdx, 'unexpected tag ');
ELSE headerContext:=2; END IF;
ELSIF (tagName='BODY') THEN
IF (Fides IIContext!=1 OR headerContext0)
THEN ERROR(lineCount, bgnTagIdx, 'unexpected tag ');
ELSE bodyContext:=1; END IF;
ELSIF (tagName='/BODY') THEN
IF (Fides IIContext!=1 OR headerContext(.*)$/) {
$tagName = $1;
$restOfLine = $2;
if ($tagName eq "FIDES II") {
if (($Fides IIContext>0) || ($headerContext>0) || ($bodyContext>0))
{ error($lineCount, "unexpected tag "); }
else { $Fides IIContext = 1; }
}
elsif ($tagName eq "/FIDES II") {
if (($Fides IIContext!=1) || ($headerContext!=2) || ($bodyContext==1))
{ error($lineCount, "unexpected tag "); }
else { $Fides IIContext = 2; }
}
elsif ($tagName eq "HEAD") {
if (($Fides IIContext!=1) || ($headerContext>0) || ($bodyContext>0))
{ error($lineCount, "unexpected tag "); }
else { $headerContext = 1; }
}
elsif ($tagName eq "/HEAD") {
if (($Fides IIContext!=1) || ($headerContext!=1) || ($bodyContext>0))
{ error($lineCount, "unexpected tag "); }
else { $headerContext = 2; }
}
elsif ($tagName eq "/HEAD") {
if (($Fides IIContext!=1) || ($headerContext!=1) || ($bodyContext>0))
{ error($lineCount, "unexpected tag "); }
else { $headerContext = 2; }
}
elsif ($tagName eq "BODY") {
if (($Fides IIContext!=1) || ($headerContext0))
{ error($lineCount, "unexpected tag "); }
else { $bodyContext = 1; }
}
elsif ($tagName eq "/BODY") {
if (($Fides IIContext!=1) || ($headerContext$spoolOutDir/$fileName" or Die ("Opening output file : $!");
print OUT "\n";
print OUT " \n";
print OUT " OK\n";
print OUT " Succeeded\n";
echoParam(OUT, "SYSTEM.PROBE");
echoParam(OUT, "REQUEST.REFERENCE");
echoParam(OUT, "REQUEST.AR");
print OUT " FR-ACK\n";
print OUT " TAG-SEP:default\n";
print OUT " EUROASCII\n";
print OUT " CRLF\n";
print OUT " \n";
print OUT " \n";
##########################
# Generate the body here #
##########################
print OUT " \n";
print OUT "\n";
close OUT;
7 Annex G : Character-sets
1 Names
Either "EUROASCII" or one of the character sets supported by Java 2 (JDK 1.2.0) :
|Character Encoding |Description |
|ASCII |ASCII (ISO 646-US) |
|ISO8859_1 |ISO 8859-1 |
|ISO8859_2 |ISO 8859-2 |
|ISO8859_3 |ISO 8859-3 |
|ISO8859_4 |ISO 8859-4 |
|ISO8859_5 |ISO 8859-5 |
|ISO8859_6 |ISO 8859-6 |
|ISO8859_7 |ISO 8859-7 |
|ISO8859_8 |ISO 8859-8 |
|ISO8859_9 |ISO 8859-9 |
|Big5 |Big5, Traditional Chinese |
|Cp037 |USA, Canada(Bilingual, French), Netherlands, Portugal, Brazil, Australia |
|Cp1006 |IBM AIX Pakistan (Urdu) |
|Cp1025 |IBM Multilingual Cyrillic: Bulgaria, Bosnia, Herzegovinia, Macedonia(FYR) |
|Cp1026 |IBM Latin-5, Turkey |
|Cp1046 |IBM Open Edition US EBCDIC |
|Cp1097 |IBM Iran(Farsi)/Persian |
|Cp1098 |IBM Iran(Farsi)/Persian (PC) |
|Cp1112 |IBM Latvia, Lithuania |
|Cp1122 |IBM Estonia |
|Cp1123 |IBM Ukraine |
|Cp1124 |IBM AIX Ukraine |
|Cp1250 |Windows Eastern European |
|Cp1251 |Windows Cyrillic |
|Cp1252 |Windows Latin-1 |
|Cp1253 |Windows Greek |
|Cp1254 |Windows Turkish |
|Cp1255 |Windows Hebrew |
|Cp1256 |Windows Arabic |
|Cp1257 |Windows Baltic |
|Cp1258 |Windows Vietnamese |
|Cp1381 |IBM OS/2, DOS People's Republic of China (PRC) |
|Cp1383 |IBM AIX People's Republic of China (PRC) |
|Cp273 |IBM Austria, Germany |
|Cp277 |IBM Denmark, Norway |
|Cp278 |IBM Finland, Sweden |
|Cp280 |IBM Italy |
|Cp284 |IBM Catalan/Spain, Spanish Latin America |
|Cp285 |IBM United Kingdom, Ireland |
|Cp297 |IBM France |
|Cp33722 |IBM-eucJP - Japanese (superset of 5050) |
|Cp420 |IBM Arabic |
|Cp424 |IBM Hebrew |
|Cp437 |MS-DOS United States, Australia, New Zealand, South Africa |
|Cp500 |EBCDIC 500V1 |
|Cp737 |PC Greek |
|Cp775 |PC Baltic |
|Cp838 |IBM Thailand extended SBCS |
|Cp850 |MS-DOS Latin-1 |
|Cp852 |MS-DOS Latin-2 |
|Cp855 |IBM Cyrillic |
|Cp857 |IBM Turkish |
|Cp860 |MS-DOS Portuguese |
|Cp861 |MS-DOS Icelandic |
|Cp862 |PC Hebrew |
|Cp863 |MS-DOS Canadian French |
|Cp864 |PC Arabic |
|Cp865 |MS-DOS Nordic |
|Cp866 |MS-DOS Russian |
|Cp868 |MS-DOS Pakistan |
|Cp869 |IBM Modern Greek |
|Cp870 |IBM Multilingual Latin-2 |
|Cp871 |IBM Iceland |
|Cp874 |IBM Thai |
|Cp875 |IBM Greek |
|Cp918 |IBM Pakistan(Urdu) |
|Cp921 |IBM Latvia, Lithuania (AIX, DOS) |
|Cp922 |IBM Estonia (AIX, DOS) |
|Cp930 |Japanese Katakana-Kanji mixed with 4370 UDC, superset of 5026 |
|Cp933 |Korean Mixed with 1880 UDC, superset of 5029 |
|Cp935 |Simplified Chinese Host mixed with 1880 UDC, superset of 5031 |
|Cp937 |Traditional Chinese Host miexed with 6204 UDC, superset of 5033 |
|Cp939 |Japanese Latin Kanji mixed with 4370 UDC, superset of 5035 |
|Cp942 |Japanese (OS/2) superset of 932 |
|Cp948 |OS/2 Chinese (Taiwan) superset of 938 |
|Cp949 |PC Korean |
|Cp950 |PC Chinese (Hong Kong, Taiwan) |
|Cp964 |AIX Chinese (Taiwan) |
|Cp970 |AIX Korean |
|EUC_CN |GB2312, EUC encoding, Simplified Chinese |
|EUC_JP |JIS0201, 0208, 0212, EUC Encoding, Japanese |
|EUC_KR |KS C 5601, EUC Encoding, Korean |
|EUC_TW |CNS11643 (Plane 1-3), T. Chinese, EUC encoding |
|GBK |GBK, Simplified Chinese |
|ISO2022CN |ISO 2022 CN, Chinese |
|ISO2022CN_CNS |CNS 11643 in ISO-2022-CN form, T. Chinese |
|ISO2022CN_GB |GB 2312 in ISO-2022-CN form, S. Chinese |
|ISO2022JP |JIS0201, 0208, 0212, ISO2022 Encoding, Japanese |
|ISO2022KR |ISO 2022 KR, Korean |
|JIS0201 |JIS 0201, Japanese |
|JIS0208 |JIS 0208, Japanese |
|JIS0212 |JIS 0212, Japanese |
|KOI8_R |KOI8-R, Russian |
|MS874 |Windows Thai |
|MacArabic |Macintosh Arabic |
|MacCentralEurope |Macintosh Latin-2 |
|MacCroatian |Macintosh Croatian |
|MacCyrillic |Macintosh Cyrillic |
|MacDingbat |Macintosh Dingbat |
|MacGreek |Macintosh Greek |
|MacHebrew |Macintosh Hebrew |
|MacIceland |Macintosh Iceland |
|MacRoman |Macintosh Roman |
|MacRomania |Macintosh Romania |
|MacSymbol |Macintosh Symbol |
|MacThai |Macintosh Thai |
|MacTurkish |Macintosh Turkish |
|MacUkraine |Macintosh Ukraine |
|SJIS |Shift-JIS, Japanese |
|UTF8 |UTF-8 |
2 Unicode encoding
The Unicode (ISO-10646) hold 256 groups of 256 planes of 256 rows of 256 characters. The 'plane 1' (U-0001XXXX) holds most of the characters frequently used in the world (excepted special characters like music symbols, …).
All characters of plane 1 (also called Basic Multilingual Plane, BMP) can be encoded on 16 bits. The 8 highest rank bits giving the row number, and the 8 lowest rank bits giving the character number in the row.
Note that row 0 (\u00XX) corresponds exactly to ISO Latin 1 (ISO 8859-1). So the ISO Latin 1 character \xXX can be converted into the Unicode character \u00XX (in the BMP).
Also note that the low half (bit 8 = 0) of all ISO-8859 character sets correspond exactly to ASCII-US (7 bits) (ISO 646-US), so their number remain the same.
The Cp1252 character set (Windows Latin 1) is almost the same as ISO 8859-1 with some extra 'funny' characters (#x80 to #x9F).
UTF-8 is a way of encoding Unicode characters on a multibyte basis (each character is represented by 1 to 6 bytes of 8 bits).
See also [TU7] and [TU8] for more information.
8 Annex H : Presentation Types
The following presentation types will be possible :
• StartTagEndTag-StartTagEndTag
(eg : fieldDatafieldData )
• StartTagEndTag-StartTagTerminator
(eg : fieldData;fieldData; )
• StartTagEndTag-Terminator
(eg : fieldData;fieldData; )
• StartTagEndTag-FixedSize
(eg : fieldData fieldData )
• StartTagTerminator-StartTagEndTag
(eg : fieldDatafieldData[EOL] )
• StartTagTerminator-StartTagTerminator
(eg : fieldData;fieldData;[EOL] )
• StartTagTerminator-Terminator
(eg : fieldData;fieldData;[EOL] )
• StartTagTerminator-FixedSize
(eg : fieldData fieldData[EOL] )
• Terminator-StartTagEndTag
(eg : fieldDatafieldData[EOL] )
• Terminator-StartTagTerminator
(eg : fieldData;fieldData;[EOL] )
• Terminator-Terminator
(eg : fieldData;fieldData;[EOL] )
• Terminator-FixedSize
(eg : fieldData fieldData[EOL] )
• HtmlFlow
(eg : ...fieldDatafieldDataw...)
-----------------------
[1] A-Grade, responsible for the co-ordination of the project, should be in a position to take decision concerning the development of the system.
[2] A or B-Grade, responsible for the day-to-day operation of the system.
[3] See section 8.8.
[4] In case of a default value specified in the field format and reception of an empty or a non-existing field value, this last one will be replaced by the default value. This is the only exception to the rule.
[5] With the terminology used in this document, this paragraph will be now translated to "All records of a body can be of one RecordPresentation. In the FR-REPLY, FR-ACK-XIV, LI-REPLY messages, the records used are a combination of FixedSize and StartTagTerminator records. In Fides II, those message bodies should only contain one type of presentation records.
[6] should be replaced by .
[7] See RD4
[8] Ordered records must be understood as SEP (separated records in a particular order).
[9] A remark has been raised by DGXIV. There should be a possibility, offered by FIDES II or the business process, to provide the time spent in processing within the business process Fides II header parameters names have changed since ISD 00.00 EN 06. A mapping table between the old parameter names and the new one’s is written in section 8.4.
[10] Format is not strictly equivalent to structure, but those parameters play the same role, since a format uniquely defines 1 structure.
[11] idem
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- job specification for finance manager
- system requirements specification example
- person specification manager
- job specification and job description
- system requirement specification template
- system verilog specification pdf
- ammo specification chart
- systemverilog interface class
- interface parameter systemverilog
- virtual interface in systemverilog
- interface system verilog
- pdf specification pdf