Earth Observation Payload Data Ground Systems Infrastructure Evolution LTDP SAFE. Representation Language Trade-off

Transcription

1 Earth Observation Payload Data Ground Systems Infrastructure Evolution LTDP SAFE Representation Language Trade-off Ref: PDGS-SAFE-GMV-TN-02/0070 Version: 1.0 Date: 11th May 2012 Author Adrian Sanz, GMV 11/05/2012 Reviewer Approver X A. Sanz GMV SAFE Project Manager Firmado por: Adrián Sanz Díaz The work described in this document was performed under ESA Contract. Responsibility for the contents resides in the author or organisation that prepared it. GMV 2012; all rights reserved (GMVAD 20738/12 V1/12) This document shall only be reproduced for the agreed purpose for which it has been supplied.

2 Table of Contents 1 Introduction Purpose Scope Document Status Applicable Documents References Acronyms and Abbreviations Current status... 3 Representation information languages Data Format Description Language (DFDL) Enhanced Ada Subset (EAST) Binary XML description language (BinX) Structured Data File (SDF) Languages Assessment Standardisation Open source specification XML based Semantic capability Bit-level representation Tools availability Documentation Language stability Results... 5 Conclusions Representation Language Trade-off page 2 of 37

3 List of Figures Representation Language Trade-off Figure 2-1:... Representation Language Trade-off page 3 of 37

4 List of Tables Representation Language Trade-off Table 1-1: Applicable Documents... 5 Table 1-2: Reference Documents... 6 Table 1-3: Acronyms... 6 Table 4-1: Standardisation assessment Table 4-2: Open Source assessment Table 4-3: XML based assessment Table 4-4: Semantic assessment Table 4-5: Bit-level representation assessment Table 4-6: Tools availability assessment Table 4-7: Documentation availability assessment Table 4-8: Language stability assessment... Table 5-1: Language comparison summary table Representation Language Trade-off page 4 of 37

5 1 Introduction 1.1 Purpose 1.2 Scope This document provides the trade-off of the existing representation languages that can be adopted for the LTDP SAFE project. The purpose of this document is to analyse the existing languages available nowadays. The aim of this document is to present a trade-off of the available representation languages identified as candidates for LTDP SAFE project. The aim is to find an alternative to the existing representation language used in SAFE. 1.3 Document Status This is the first version of the document issued for open discussion in the SAFE Wiki/Forum web page ( before the PDR-C. 1.4 Applicable Documents The following table lists the Applicable Documents that have a direct impact on the contents of this document. Acronym Title Reference Issue [SRR_REP] SAFE SRR Review Report SAFE-GMV-REP [DFDL_SPEC] Data Format Description GFD-P-R Language Specification [EAST_SPEC] Data Description Language CCSDS B-3 3 EAST Specification (Blue Book) [DEDSL_SPEC] Data Entity Dictionary CCSDS B Specification Language [BINX_DEV] BinX 1.2 Developer s EPCC-GDS-WP5-BinX 1.3 Guide [DRB_UM] DRB API Handbook GAEL-P243-DOC Table 1-: Applicable Documents 1.5 References Acronym Title Reference Issue [SSS] Software System SAFE-GMV-SSS Specification [BEST_UM] BEST User Manual Ed.2 Rev January 25, [BINXLIB_INST] BinX 1.2 Installation Guide Ed [BINXED_UM] BinXed 1.0 Users s Guide Ed OGF DFDL general information Representation Language Trade-off page 5 of 37

6 Acronym Title Reference Issue Daffodil DFDL Parser CCSDS web page ois.edu/confluence/display/ DFDL/Home Table 1-: Reference Documents 1.6 Acronyms and Abbreviations Acronym AIP BEST CCSDS CNES DEBAT DEDSL DFDL DRB DSDL EO ISO LGPL OAIS PDGS PDR-C PVL SAFE SDF SRR SSS XML XSD Meaning Archive Information Packages Beyond EAST Consultative Committee for Space Data Systems Centre National d Etudes Spatiales Development of EAST Based Access Tools Data Entity Dictionary Specification Language Data Format Definition Language Data Request Broker Data Structure Description Language Earth Observation International Organization for Standardization GNU Lesser General Public License Open Archival Information System Payload Data Ground System Preliminary Design Review Core Parameter Value Language Satellite Archive Format for Europe Structured Data File Software Requirements Review Software System Specification extensible Markup Language XML Schema Definition Table 1-: Acronyms Representation Language Trade-off page 6 of 37

7 2 Representation information Representation Language Trade-off According the OAIS definition, representation information is the information that maps a Data Object (either a physical or a digital object) into more meaningful concepts. In other words, representation information maps the data bits (within a data file) to data values (such as numbers and strings) and then shows how these values are ordered with respect to one another within the data hierarchy. The language used to specify the representation information should be able to provide: Logical description: hierarchical structure of the values in the data file. Physical description: structure of the individual bits and how they map to atomic types (integers, reals, characters, arrays and strings). The current SAFE format makes use of XML Schemas to represent binary and text data files. These XML Schemas are augmented using annotations mark-ups complementing the description of binary contents where XML Schema language is not enough e.g. binary offsets, field lengths, encoding, etc. even dynamically computed. The annotation mark-ups approach is commonly used by several commercial systems nowadays but the current implementation used in SAFE is not standard and was specified by a private company, which is a risk for the long-term data preservation of the SAFE products. Representation Language Trade-off page 7 of 37

8 3 Language candidates The following languages have been identified as possible candidates suitable for SAFE. Next sections present the main characteristics of each one. 3.1 Data Format Description Language (DFDL) Description DFDL is a standardised open source language intended for data commonly found in scientific and numeric computations, as well as record-oriented representations found in commercial data processing. DFDL can be used to describe legacy data files, to simplify transfer of data across domains without requiring global standard formats, or to allow third-party tools to easily access multiple formats. DFDL makes use of the XML technology and provides flexibility to represent different data sources. DFDL also permit implementations that achieve very high levels of performance. DFDL is an open source standard language supported by the Open Grid Forum (OGF) 1. The OGF is an open community committed to the rapid evolution and adoption of applied distributed computing through activities which explore trends, share best practices and consolidate these best practices into standards. DFDL has been standardised by the OGF DFDL Working Group (DFDL-WG) as part of the Data Area within the OGF Standards function. This working group is devoted to define an XML-based language (DFDL) for describing the structure of binary and textual files and data streams so that their format, structure, and metadata can be exposed. OGF cooperates with ISO under Liaison A level defined for those organisations making effective contribution to the work of the ISO technical committee or subcommittee Characteristics DFDL can be used to describe binary and text data up to the bit-level based on the W3C XML Schema specification 2. The XML schema used by DFDL is used for the logical model of the data but enhanced with special annotations which are used to describe the native (non-xml) format of the data. This is an accepted approach that is already being used today in commercial systems. DFDL evolves this approach into an open standard capable of describing almost any format of text or binary data. DFDL allows general semantic labels: for example international system units, SQL types, time or more specific labels like for example nodecolour = red Representation Language Trade-off page 8 of 37

9 An example of DFDL representation can be found in Appendix A Some of the main relevant features of the current DFDL specifications are: Support for multiple streams Conditional logic (if, choice, any) Basic math operations (+,-,*,/) Looping Pattern matching for text/binary delimiters External transforms Reference values within schema (for sequence length, delimiters, etc) Layering (hidden elements that can be referenced, but do not display in output) The following features are not supported in the current version of the specification but it is expected to be done for future releases of the DFDL language specification: Related tools Direct data access by offset True multi-dimensional arrays Embedded comments Custom language extensions There are commercial (IBM WebSphere Message Broker) and open source (Daffodil) implementations of DFDL processors that can parse and serialize data using DFDL schemas. Daffodil is a DFDL open source parser supported by the US National Archives and Records Administration (NARA) and the National Center for Supercomputing Applications (NCSA) at the University of Illinois. Nowadays it s being evaluated to assess its conformance with the DFDL standard specification v1.0. Daffodil is the candidate to be the first reference implementation of the DFDL standard. Daffodil make use of a DFDL annotated schema and a data file as input. The schema is parsed and a parser for the DFDL is generated and run. The result is a DOM tree in memory (i.e., in Java data structures), which, by default, is an XML output. Semantic extensions are also foreseen to extend the DFDL model to support mapping to semantic web languages: Resource Description Framework (RDF) Web Ontology Language (OWL) Documentation DFDL standard Specification v1.0 [DFDL_SPEC] was published on December The specification is accessible to all users at the OGF web page and it contains detailed information about the language. Representation Language Trade-off page 9 of 37

10 Daffodil documentation is also open and accessible to all users, but it is not still consolidated as it is pending to be validated with the recent DFDL specification Enhanced Ada Subset (EAST) Description EAST is a formal data description language to describe binary and text data down to whatever level of detail. In association with the Data Entity Dictionary Specification Language (DEDSL), it allows syntax and semantics of any data structure to be described independently of any application requiring accessing the data for whatever purpose. EAST is a subset of the Ada programming language and contains therefore most of the declarative features of Ada, but no algorithmic features. In the other hand, DEDSL allows to add semantic information to data by means of semantic attributes using XML or PVL languages. EAST and DEDSL specification have been endorsed as ISO standards and as a Recommendation for Space Data Standards by the Consultative Committee for Space Data Systems (CCSDS). CCSDS is an organization officially established by the management of its members. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate technical solutions to these problems. The results of Committee actions are termed Recommended Standards Characteristics An EAST Data Description is a text file composed of lexical elements: the 128 first characters of the Latin Alphabet No. 1. The logical part of an EAST description provides syntactic information of the data while the physical part description, provides a bit-level description that ensures the non-ambiguous interpretation of the data. The EAST language is based on the Ada syntax but it contains additional semantic information, so an Ada Compiler may not sufficient to ensure the consistency of an EAST Data Description Record. The definition of the semantic information of a data file can be provided by a DEDSL description text file. It defines the semantic information and presents the specification in a layered manner by using attributes, entities and dictionaries. This allows the semantic information to be translated to different representations if needed, when data are transferred between different systems. There are two standard specifications to define such DEDSL representation file using XML or PVL. An example of EAST/DEDSL representation can be found in Appendix B 3 Representation Language Trade-off page 10 of 37

11 Some important limitations (that cannot be solved using other alternatives within this language) have been identified: Discrete discriminants: Only enumeration types and integer types are allowed to discriminate records. Character Set: EAST is only able to use "Latin Alphabet No. 1" character set. There is no flexibility to use other widely used standards as for example Unicode. Array Storage applicability: The array storage method is applicable to the whole description. If a data set is composed of data from different sources, all the arrays must be stored in the same way Related tools DEBAT was a CNES and ESA project which main objective was to build a set of enhanced tools upon the EAST technologies. This project concluded on April 2005 and the outcome was a tool suite called BEST (Beyond EAST). BEST is a set of enhanced tools upon the EAST technologies supporting the entire data life cycle: modelling/definition, producing/generating, editing, accessing, checking, processing, extracting, querying, post-processing. CNES provides the BEST tool suite as a binary executable software (no source code is available) Documentation Last version of the EAST standard Specification [EAST_SPEC] was published on June 2010 and provides the syntax and semantic rules for EAST itself. DEDSL specification [DEDSL_SPEC] was issued on June 2001 and reconfirmed by the CCSDS management Council through March 2011 Both documents are accessible to all users at the CCSDS web page 4. The only available documentation for BEST suite tool is the User Manual [BEST_UM] and can be found at a CNES s freeware server 5. This document does not provide information about the internal libraries and it is focused on how to operate the tool suite. 3.3 Binary XML description language (BinX) Description The BinX language is an application-specific markup language used to describe binary data files (it is a dialect of XML, and is therefore itself defined syntactically in an XML schema.). The BinX language codifies some meta-data about binary data files, the elements (tags) in the language Representation Language Trade-off page 11 of 37

12 identify the binary file, its data structure elements, and also the individual fields in the file. The motivation for the BinX language is to give some of the virtues of XML tag language representation (relatively easy for humans to understand and make sense of) without losing the compactness of binary data. The language have been developed within the edikt (e-science Data, Information and Knowledge Transformation) initiative at the National e- Science Centre 6 in UK Characteristics BinX is an open source representation language able to describe primitive data types such as character, byte, integer and floating point, and to represent data structures of sequences, arrays and unions. The representation information is a simple XML document based on a XML schema for BinX (binx.xsd). A single BinX document maps to a particular binary data file, and can describe complex data structures. An example of BinX representation can be found in Appendix C BinX provides the ability to describe three levels of features in a binary file: The underlying physical representation (e.g. byte ordering) The primitive types used (e.g. IEEE float, integer) The structure of the data itself (e.g. array, list of fields, table) But it has various limitations: It s not possible to describe a binary structure with variable number of records where the number is described (dynamically) within the binary itself. it would be impossible to represent a number given in a vendorspecific floating-point type. It would, of course, be possible to notate it as a fixed array of bytes, but the semantics of the floating-point representation would be opaque. the typedef mechanism cannot be parameterised. If additional parameterised type definitions are necessary, the user will have to extend the schema itself. There is no new release of BinX since 2005 (when the initial phase of the edikt project ended). However it is intended to produce regular releases to the community and it are foreseen future releases of BinX including support for text (flat) files. 6 Representation Language Trade-off page 12 of 37

13 3.3.3 Related tools The BinX library is supplied as a pre-compiled free to download product that provides basic reading and writing operations for a BinX data source. A BinX data source is composed of a data file, usually a binary data file, and a separate text file describing the data schema using the BinX language. The BinX Library is a middleware package supporting the BinX model by providing access to large binary data files through a BinX document. The BinX Library provides three levels of service: Implements a broad range of generic utilities that solve common data transformation problems, Defines and exports a high-level API for easy application development by scientists who need to access binary datasets, and Defines and exports a flexible mid-range API supporting the development of potentially complex data translation and transformation tools by software developers, such as the edikt team. The BinX Editor (BinXed) is a visualisation tool to help design BinX documents providing a GUI to add elements, browse, edit, validate, etc a BinX document. It is a Java application developed for Solaris, Linux and Windows. The pre-compiled version of these tools can be downloaded from the edikt web page 7 for each of the supported systems. Both BinX library and BinX Editor Source code is available for academic users purposes only Documentation There is no formal BinX language specification but [BINX_DEV] containing information details on the language. For the BinX library there is an installation guide for the BinX library [BINXLIB_INST] and the API reference as well. For the BinX Editor a software guide is also available [BINXED_UM]. All these documents are accessible to all users at Edikt web page. 3.4 Structured Data File (SDF) Description SDF is a mark-up language that allows the physical and logical description of data structures and file formats through the use of a XML schema by providing specific description tags which can describe a data format down to the bit level. This is the representation language currently used by the SAFE format, and it is compliant with a proprietary specification defined by GAEL Consultant. 7 Representation Language Trade-off page 13 of 37

14 This language has been included in the present trade-off to provide a reference point for the languages alternatives that can be used in SAFE. SDF will be used again by SAFE just in case of the available languages are not able to cover all the current functionality provided by SDF. Additionally, the LGPL license has been adopted recently for some of the tools provided by this company so an analysis is needed to clarify if this license is also applied to the SDF specification Characteristics SDF is a proprietary language able to describe binary and text data up to the bit-level based on the W3C XML Schema specification 8. A data file is usually defined as a set of adjacent blocks with various lengths containing binary or text data which can be described as a hierarchy of data blocks. These blocks are organized in a "tree model" as a file system does with directories, subdirectories and files. A logical description is first needed to set up the structure of the tree. To do so the XML-Schema language has been chosen. To remain open to other content types where flat files or XML documents would not be suitable, SDF allows binary components provided along with their Representation Information. This Representation Information is provided as an XML Schema annotated with SDF mark-ups. These mark-ups complements the description of binary contents where XML Schema language is not enough e.g. binary offsets, field lengths, encoding, etc. even dynamically computed. An example of SDF representation can be found in Appendix D Related tools The Data Request Broker (DRB) API is an Open Source Java application programming interface provided by GAEL Consultant for reading, writing and processing heterogeneous data. This tool is available under LGPL version 3 license and can be downloaded from the GAEL Consultant s web page Documentation There are some SDF specifications included in the SAFE core specification but it is not easy to follow. For the DRB API, there is only user manual [DRB_UM] issued in 2008 that can be found at GAEL web page 10 but the content is specified as draft Representation Language Trade-off page 14 of 37

15 version. This document also includes some information on the SDF language. Representation Language Trade-off page 15 of 37

16 4 Languages Assessment The languages presented above have been analysed according the following parameters that are considered relevant for the SAFE project: Standardisation Open source specification XML based Semantic capability Bit-level representation Tools availability Documentation The parameters described above have been assessed according the following criteria: 4.1 Standardisation (0) : Not compliant with SAFE needs (1) : Roughly compliant with SAFE (2) : Partially compliant with SAFE needs (3) : Fully compliant with SAFE needs The use of standard languages has been identified as one of the major requirements identified for SAFE. At this point, both DFDL and EAST language specifications have been standardised by OGF and CCSDS respectively and are suitable for SAFE in this aspect. On the contrary, BinX and SDF languages are not standard languages and there is a lack of formal specification for both of them. DFDL EAST BinX SDF Standardisation Table 4-: Standardisation assessment 4.2 Open source specification Other relevant aspect to be considered in the representation language adoption for SAFE is the need to use open source solutions to assure that the language will be available in the long-term and no licenses restrictions will impact in the preservation of the data. In that sense, DFDL and EAST specifications are open source and there are no specific licenses restricting the use of these languages in any way. Representation Language Trade-off page 16 of 37

17 BinX specification is also an open source language, but the existence of a license for academic purposes on the BinX library, seems that the specification could be affected in the future. On the other hand, SDF is an open source language that apparently seems to be affected by the LGPL license provided for DRB. However, the language specification belongs to a private company that could restrict the usage in the future. DFDL EAST BinX SDF Open source specification Table 4-: Open Source assessment 4.3 XML based In order to assure backward compatibility with previous SAFE version, the new representation language should be based on XML standard. Thus, BinX language provides representation information in a XML document for binary data objects. This XML document is supported by a XML Schema which is common to all representation information files. DFDL and SDF are also based in XML but provide a different approach to BinX in order to provide more flexibility to represent binary and text data. Both languages are using an XML Schema enhanced with annotation tags. The representation information provided by EAST is based on Ada programming language therefore this language seems to be not adequate in that sense. DFDL EAST BinX SDF XML based Table 4-: XML based assessment 4.4 Semantic capability Current representation language used in SAFE provides limited semantic capability to represent data objects. The new representation language should increase this semantic level capability or, at least, it should provide the same semantic level capability as it is being provided within the current SAFE specification. EAST is able to provide syntax and semantics of any data structure if it is used in combination with DEDSL. This makes EAST as suitable candidate for SAFE as the semantic level is increased in comparison with the current level provided by SAFE. However, the addition of a new element (DEDSL) could increase the level of complexity to represent the information, but at this point, the combination EAST/DEDSL can be considered as fully acceptable for SAFE semantics needs. DFDL and SDF provide the same semantic capability level. Thus, both languages are considered adequate for SAFE needs. Representation Language Trade-off page 17 of 37

18 BinX supports limited semantics and the extensibility is not one of the strong points of this language. As results, this language seems not to cover all the necessities identified for SAFE. DFDL EAST BinX SDF Semantic capability Table 4-: Semantic assessment 4.5 Bit-level representation The language used for the presentation information should be capable to describe data object structures up to bit level, as it is being done by the current language used by SAFE. DFDL, EAST and SDF are able to provide bit-level description of data object structures. However, BinX makes use of fixed tags for primitive data types but it doesn t provides bit support. DFDL EAST BinX SDF Bit-level representation Table 4-: Bit-level representation assessment 4.6 Tools availability Long-term tool availability is a must for SAFE in order to assure the manipulation of the archived products in the future. In that sense, it is assumed that the language used for representation information should be supported by an extensive and freely available set of tools. These tools (if exist) should be also well documented to guarantee its correct use in the long-term. As presented in section 4, none of the considered languages are supported by an extensive set of tools. DFDL, BinX and SDF are supported by a limited set of open source tools, and in some cases the documentation associated to these tools is not consolidated or is not very detailed. The case of EAST is different, it exists a tool suite providing support for the whole data life cycle (modelling/definition, producing/generating, editing, accessing, checking, processing, extracting, querying, post-processing) but it is only available as a precompiled (no open-source) for certain operating systems. DFDL EAST BinX SDF Tools availability Table 4-: Tools availability assessment Representation Language Trade-off page 18 of 37

19 4.7 Documentation The representation information language to be used by SAFE should be well specified and the appropriate documentation should be freely accessible to be used in the long-term. As standard languages, DFDL and EAST are accompanied by detailed documentation about each specification. In this case documentation is rigorous and clear and the preservation is assured by the OGF and CCSDS organisations. In the other hand, the existing documentation for the specification of both BinX and SDF is not formal, and it is spread along different a document that sometimes is not easy to follow. DFDL EAST BinX SDF Documentation Table 4-: Documentation availability assessment Representation Language Trade-off page 19 of 37

20 5 Conclusions Four representation languages have been analysed as possible candidates to be adopted by SAFE. The outcomes of this analysis can be summarised as follows: DFDL - Pros o Open source standard language (supported by OGF). o Based in XML representation schemas. o Allows representation of information at bit-level. o Semantic information at the same level as current representation language used in SAFE. o Documentation well specified and available for public access. - Cons o Recently standardised (possible changes could appear in the shortterm). o Open source tools are not yet consolidated. EAST - Pros o Open source standard language (supported by CCSDS). o Allows representation of information at bit-level. o Good semantic information when using with DEDSL o Well specified documentation and available for public access - Cons o Not based in XML o Existing tool suite is not open source o Some features are missing to represent complex data formats o Limited character set (Unicode cannot be used). BinX - Pros o Open source language (developed within the Editk project) o Based in XML document for data representation. o Allows representation of information at bit-level. - Cons o Not standard. o Rigid representation language (fixed set of data types). o Limited semantic capability. o Limited text data representation capability. o Open source tools only available under academic licensing. SDF - Pros o Open source language (supported by Gael Consultant). o Based in XML representation schemas. o Allows representation of information at bit-level. o Semantic information at the same level as current representation language used in SAFE. o Open Source tools under LGPL license Representation Language Trade-off page 20 of 37

21 - Cons o Not standard. o Proprietary language specification o Very similar to DFDL o Documentation not consolidated The following table provides a quantitative approach and tries to show at which level the SAFE needs are covered by the analysed languages: DFDL EAST BinX SDF Standardisation Open source specification XML based Semantic capability Bit-level representation Tools availability Documentation Mean Where (0) : Language is not compliant with SAFE needs (1) : Language is roughly compliant with SAFE (2) : Language is partially compliant with SAFE needs (3) : Language is fully compliant with SAFE needs Table 5-: Language comparison summary table According the presented results and the information provided in previous sections, the Data Format Description Language (DFDL) seems to be the best alternative for SAFE. Representation Language Trade-off page 21 of 37

22 Appendix A Example of representation information in DFDL This example has been taken from [DFDL_SPEC] A.1 DFDL representation information: <xs:complextype > <xs:sequence dfdl:byteorder="bigendian"> <xs:element name="w" type="xs:int"> <xs:annotation> <xs:appinfo source= > <dfdl:element representation="binary" binarynumberrep="binary" byteorder="bigendian" lengthkind="implicit"/> </xs:appinfo> </xs:annotation> </xs:element> <xs:element name="x" type="xs:int "> <xs:annotation> <xs:appinfo source= > <dfdl:element representation="binary" binarynumberrep="binary" byteorder="bigendian" lengthkind="implicit"/> </xs:appinfo> </xs:annotation> </xs:element> <xs:element name="y" type="xs:double"> <xs:annotation> <xs:appinfo source= > <dfdl:element representation="binary" binaryfloatrep="ieee" byteorder="bigendian" lengthkind="implicit"/> </xs:appinfo> </xs:annotation> </xs:element> <xs:element name="z" type="xs:float" > <xs:annotation> <xs:appinfo source= > <dfdl:element representation="binary" byteorder="bigendian" lengthkind="implicit" binaryfloatrep="ieee" /> </xs:appinfo> </xs:annotation> </xs:element> </xs:sequence> </xs:complextype> Representation Language Trade-off page 22 of 37

23 Appendix B Example of representation information in EAST/DEDSL This example has been taken from B.1 EAST representation information: date generation :Wed Oct 20 18:07:54 CEST package logical_new0_sun_fcstc000 is EAST_VERSION : constant STRING := "5.0"; -- MODELLER_VERSION : constant STRING := "5.0"; subtype DEBUT_TYPE is STRING(1.. 30) ; type AN_TYPE is range ; for AN_TYPE'size use 32 ; type MOIS_TYPE is range ; for MOIS_TYPE'size use 16 ; type JOUR_TYPE is range ; for JOUR_TYPE'size use 16 ; type SECONDE_DU_JOUR_TYPE is digits 8 range ; for SECONDE_DU_JOUR_TYPE'size use 80 ; type DATE_TYPE is record AN : AN_TYPE := 0; MOIS : MOIS_TYPE := 1; JOUR : JOUR_TYPE := 1; SECONDE_DU_JOUR : SECONDE_DU_JOUR_TYPE ; end record ; for DATE_TYPE use record AN at 0 * WORD_16_BITS range ; MOIS at 2 * WORD_16_BITS range ; JOUR at 3 * WORD_16_BITS range ; SECONDE_DU_JOUR at 4 * WORD_16_BITS range ; end record ; for DATE_TYPE'size use 144 ; subtype FIN_TYPE is STRING(1.. 40) ; DEBUT : DEBUT_TYPE ; DATE : DATE_TYPE ; FIN : FIN_TYPE ; end logical_new0_sun_fcstc000 ; package physical_new0_sun_fcstc000 is type BIT_ORDER is (HIGH_ORDER_FIRST, LOW_ORDER_FIRST) ; OCTET_STORAGE : constant BIT_ORDER := HIGH_ORDER_FIRST ; type ASCII_NUMERIC_PHYSICAL_DESCRIPTION is record NUMBER_OF_CHARACTERS : NATURAL ; end record ; type BASIC_TYPE_NAMES is (USER_TYPE_SECONDE_DU_JOUR_TYPE, USER_TYPE_JOUR_TYPE, USER_TYPE_AN_TYPE, USER_TYPE_MOIS_TYPE) ; ASCII_Representation_1 : constant ASCII_NUMERIC_PHYSICAL_DESCRIPTION := (NUMBER_OF_CHARACTERS => 4) ; ASCII_Representation_2 : constant ASCII_NUMERIC_PHYSICAL_DESCRIPTION := (NUMBER_OF_CHARACTERS => 2) ; ASCII_Representation_3 : constant ASCII_NUMERIC_PHYSICAL_DESCRIPTION := (NUMBER_OF_CHARACTERS => 10) ; Representation Language Trade-off page 23 of 37

24 type RELATION (CHOICE : BASIC_TYPE_NAMES) is record case CHOICE is when USER_TYPE_SECONDE_DU_JOUR_TYPE => PHYS_SECONDE_DU_JOUR_TYPE : ASCII_NUMERIC_PHYSICAL_DESCRIPTION := ASCII_Representation_3 ; when USER_TYPE_JOUR_TYPE => PHYS_JOUR_TYPE : ASCII_NUMERIC_PHYSICAL_DESCRIPTION := ASCII_Representation_2 ; when USER_TYPE_AN_TYPE => PHYS_AN_TYPE : ASCII_NUMERIC_PHYSICAL_DESCRIPTION := ASCII_Representation_1 ; when USER_TYPE_MOIS_TYPE => PHYS_MOIS_TYPE : ASCII_NUMERIC_PHYSICAL_DESCRIPTION := ASCII_Representation_2 ; end case ; end record; end physical_new0_sun_fcstc000 ; B.2 DEDSL description: <?xml version="1.0" encoding="iso "?> <!--DOCTYPE DATA_ENTITY_DICTIONARY SYSTEM "DEDSL.DTD"--> <DATA_ENTITY_DICTIONARY> <!--Data Entity Dictionary attributes--> <DICTIONARY_IDENTIFICATION> <DICTIONARY_NAME CASE_SENSITIVITY="CASE_SENSITIVE" >NEW0</DICTIONARY_NAME> <DICTIONARY_LANGUAGE ISO_CODE="en" IN_ENGLISH="English"/> <DEDSL_VERSION>CCSDS B-1</DEDSL_VERSION> <DICTIONARY_USER_DEFINED_ATTRIBUTES> <CREATION_DATE>Thu Sep 00:00: </CREATION_DATE> <MODELLER_VERSION>5.0 </MODELLER_VERSION> <DICTIONARY_STATUS>DRAFT</DICTIONARY_STATUS> </DICTIONARY_USER_DEFINED_ATTRIBUTES> </DICTIONARY_IDENTIFICATION> <!-- Dictionary entities --> <!-- Constants --> <!-- Types --> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="AN_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <INTEGER_TYPE> <INTEGER_RANGE MIN="0" MAX="4000"/> </INTEGER_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>32</LENGTH> <NATURE>INTEGER</NATURE> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="MOIS_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <INTEGER_TYPE> <INTEGER_RANGE MIN="1" MAX="31"/> </INTEGER_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>16</LENGTH> <NATURE>INTEGER</NATURE> </USER_DEFINED_ATTRIBUTES_PART> Representation Language Trade-off page 24 of 37

25 </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="JOUR_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <INTEGER_TYPE> <INTEGER_RANGE MIN="1" MAX="31"/> </INTEGER_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>16</LENGTH> <NATURE>INTEGER</NATURE> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="SECONDE_DU_JOUR_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <REAL_TYPE> <REAL_RANGE MIN="0" MAX="86400"/> </REAL_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>32</LENGTH> <NATURE>REAL</NATURE> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="DEBUT_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <COMPOSITE_TYPE> </COMPOSITE_TYPE> <TEXT_TYPE> <TEXT_SIZE MIN="0" MAX=""/> </TEXT_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>240</LENGTH> <NATURE>CHARACTER_STRING</NATURE> <INDEX>("1.. 30")</INDEX> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="FIN_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <COMPOSITE_TYPE> </COMPOSITE_TYPE> <TEXT_TYPE> <TEXT_SIZE MIN="0" MAX=""/> </TEXT_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>320</LENGTH> <NATURE>CHARACTER_STRING</NATURE> <INDEX>("1.. 40")</INDEX> </USER_DEFINED_ATTRIBUTES_PART> Representation Language Trade-off page 25 of 37

26 </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="MODEL" NAME="DATE_TYPE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <COMPOSITE_TYPE> <COMPONENT>AN</COMPONENT> <COMPONENT>MOIS</COMPONENT> <COMPONENT>JOUR</COMPONENT> <COMPONENT>SECONDE_DU_JOUR</COMPONENT> </COMPOSITE_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <LENGTH>96</LENGTH> <NATURE>RECORD</NATURE> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- Variables --> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="DEBUT"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>DEBUT_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <TEXT_TYPE> <TEXT_SIZE MIN="0" MAX="30"/> </TEXT_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DEBUT</EAST_PATH> <LENGTH>240</LENGTH> <NUMBER>1</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="DATE"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>DATE_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DATE</EAST_PATH> <DECOMPOSITION></DECOMPOSITION> <LENGTH>96</LENGTH> <NUMBER>2</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="AN"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>AN_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DATE.AN</EAST_PATH> <LENGTH>32</LENGTH> <NUMBER>1</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> Representation Language Trade-off page 26 of 37

27 <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="MOIS"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>MOIS_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DATE.MOIS</EAST_PATH> <LENGTH>16</LENGTH> <NUMBER>2</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="JOUR"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>JOUR_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DATE.JOUR</EAST_PATH> <LENGTH>16</LENGTH> <NUMBER>3</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="SECONDE_DU_JOUR"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> <UNITS>{"Not Completed"}</UNITS> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>SECONDE_DU_JOUR_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.DATE.SECONDE_DU_JOUR</EAST_PATH> <LENGTH>32</LENGTH> <NUMBER>4</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- --> <DATA_ENTITY_DEFINITION CLASS="DATA_FIELD" NAME="FIN"> <DEFINITIONAL_PART> <DEFINITION>"Not Completed"</DEFINITION> </DEFINITIONAL_PART> <RELATIONAL_PART> <INHERITS_FROM>FIN_TYPE</INHERITS_FROM> </RELATIONAL_PART> <REPRESENTATIONAL_PART> <TEXT_TYPE> <TEXT_SIZE MIN="0" MAX="40"/> </TEXT_TYPE> </REPRESENTATIONAL_PART> <USER_DEFINED_ATTRIBUTES_PART> <EAST_PATH>NEW0.FIN</EAST_PATH> <LENGTH>320</LENGTH> <NUMBER>3</NUMBER> </USER_DEFINED_ATTRIBUTES_PART> </DATA_ENTITY_DEFINITION> <!-- User attributes definitions --> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DICTIONARY">EXTERNAL_DICTIONARY_REFERENCE</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> Representation Language Trade-off page 27 of 37

28 <![CDATA[Reference to another Data Entity Dictionary whose models are re-used in the current one, defined as the local name of the Data Entity Dictionary, followed by its identifier and its associated Control Authority.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[MODELLER does not control the values of this attribute. It is the user's responsability to control the coherence of the value. The maximum size of this field - as defined by the norm - is (400, 400, 400).]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[EXTERNAL_DICTIONARY_REFERENCE = (CDPP_Plasma_Dictionary, FCST0172, ''CCSDS_Control_Authority'') ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">CHARACTER_RANGE</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Range of a character.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="80"/> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[CHARACTER_RANGE = ['A'..'Z'] ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">EAST_PATH</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents the absolute path of a data entity in a data model. This information is used by EAST tools to process datas.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_IDENTIFIER_TYPE MAX_SIZE="80"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[EAST_PATH = ""DATA_MODEL.RECORD.EL1""]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DICTIONARY">CREATION_DATE</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents the creation date of the Data Entity Dictionary.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[CREATION_DATE = ''Thu Aug 19 14:38: '' ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">TREE</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Name of the graphical representation of the data entity hierarchy tree. The file format is encapsulated postscript.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[TREE = ''./mymodel.fullded_eps/mymodel_1_tree.eps'' ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> Representation Language Trade-off page 28 of 37

29 <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">DECOMPOSITION</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Name of the file which gives a graphical representation of the data as a byte flow table, giving informations on byte position of each sub-entity contained in the entity represented.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[DECOMPOSITION = ''./mymodel.fullded_eps/entity_1_array.eps'' ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">LENGTH</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[This attribute represents the storage size of the entity in bytes.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_INTEGER_TYPE/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[LENGTH = 12 ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">NUMBER</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[This attribute represents the position of the entity in a record entity.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_INTEGER_TYPE/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[NUMBER = 1 ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">EXISTS_IF</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents the existence condition for the data entity.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute. MODELLER use a particular format for the condition expression.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[EXISTS_IF = ''DATAMODEL.RECORD.FIELD1[0..0]'' ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DICTIONARY">MODELLER_VERSION</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents the version of MODELLER whereby the Data Entity Dictionary was generated.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_TEXT_TYPE MAX_SIZE="8000"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> Representation Language Trade-off page 29 of 37

30 <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[MODELLER_VERSION = ''MODELLER V3.0 (2001)'' ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">NATURE</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[This attribute extends the DEDSL-PVL concept of type, introducing such types as LIST, RECORD or ARRAY.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_IDENTIFIER_TYPE MAX_SIZE="80"/> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[NATURE = ARRAY ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DATA">INDEX</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents either the range values of the index or the name of the entity used as an index for a composite entity.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[INDEX = (''1..13'') ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> <USER_DEFINED_ATTRIBUTE_DEFINITION> <ATTRIBUTE_NAME OBLIGATION="OPTIONAL" SCOPE="DICTIONARY">DICTIONARY_STATUS</ATTRIBUTE_NAME> <ATTRIBUTE_DEFINITION> <![CDATA[Represents the Data Entity Dictionary generation status. The RELEASE status means the dictionary is fully compatible with the DEDSL-PVL CCSDS norm. The DRAFT status is for temporary dictionaries.]]> </ATTRIBUTE_DEFINITION> <ATTRIBUTE_MAXIMUM_OCCURRENCE>1</ATTRIBUTE_MAXIMUM_OCCURRENCE> <ATTRIBUTE_ENUMERATED_TYPE> <ATTRIBUTE_ENUMERATION_VALUE>DRAFT</ATTRIBUTE_ENUMERATION_VALUE> <ATTRIBUTE_ENUMERATION_VALUE>RELEASE</ATTRIBUTE_ENUMERATION_VALUE> </ATTRIBUTE_ENUMERATED_TYPE> <ATTRIBUTE_COMMENT> <![CDATA[This is a default MODELLER attribute.]]> </ATTRIBUTE_COMMENT> <ATTRIBUTE_INHERITANCE OPTION="NOT_INHERITABLE" /> <ATTRIBUTE_VALUE_EXAMPLE> <![CDATA[DICTIONARY_STATUS = DRAFT ;]]> </ATTRIBUTE_VALUE_EXAMPLE> </USER_DEFINED_ATTRIBUTE_DEFINITION> </DATA_ENTITY_DICTIONARY> Representation Language Trade-off page 30 of 37