XML Schema WRITING RULES

CNES - DCT/PS/VDO

BEATRICE LARZUL
DENIS MINGUILLON
Arnaud LUCAS

GENERAL

This document describes the rules to be applied when writing XML diagrams within the context of the PLEIADES project.

Reference Documents

DR1	Règles pour l'élaboration de documents de description d'interface informatiques
D. Minguillon, 27/06/2002, Edit. 1, Rev. 0
RNC-CNES-E-40-507
DR2	Management of Pleiades interfaces in XML
J. Donadieu ; D. Minguillon, 24/01/2005, Edit. 00, Rev. 00
PHR-NT-0-1877-CNES
Applicable Documents

DA1	System Product Assurance Plan
30/06/2003, Edit. 1, Rev. 0
PHR-PL-0-70-CNES

CONTEXT

The Pleiades project elected to manage the interfaces in the form of data in XML syntax described by XML diagrams.

The procedure described below is therefore that which will be used to produce the schemas in question, then to maintain consistency with changes affecting the interfaces.

This document bases itself on the principles adopted in phase B, and described in note DR2, in order to specify the principles applicable for phase C/D of the project, taking account of feedback from the prototyping performed at phase B.

CHOICES OF METHODOLOGY

For simplicity, an interfaces are described by an XML schema and an XML schema describes only one interface.

An XML schema comprises data types (a calendar date, an orbit, etc.), and elements (which may or may not be typed).

The definitions of the data types used in the different interfaces are contained in a dictionary to avoid duplication.

The dictionary is organised into XML schemas r grouped according to theme:

an "orbito" theme contains all orbit-related types

a "dating" theme contains all dating-related types

The interface description files (in XML schema) use the types defined in this dictionary.

Fig 1: Interface description reference system

These XML schemas describe the hierarchical organisation of the data constituting the interface by means of an XML tree (nesting of tags). Each item of data forming this tree (node or leaf) is then described using the description criteria listed in Appendix A in accordance with [DR1].

These schemas also carry information regarding the data (metadata). This information may or may not be included in the data according to the status given to the information. It should be remembered that there are two types of element for describing a data item:

"descriptive elements" that are visible in the generated Word documentation but do not appear in the data file ( see. PROTOCOL, VOLUME and FREQUENCY attributes in Appendix A ),

"data elements" which are the fields of the data files that pass between the applications. They serve as tags designating the values.

The formalisation of the descriptive elements is given in ‎6(which lists the elements and defines the role and characteristics of each) and in chapter ‎5.6 which describes how they are implemented in PHR Schema.

This document also defines some major data structuring principles. Because the XML syntax provides freedom to elaborate numerous grammars, it was decided to specify that which would apply for describing the PLEIADES interfaces.

Based on these choices, a schema modelling this grammar was defined. This schema harmonises the description of interfaces.

Among other things, this has enabled the parameterisation of the XML Spy tool used by the managers responsible for these definitions, by defining as its basic schema the chosen grammar together with a skeleton providing the necessary descriptive elements.

The task of defining the XML schema of each interface consists of making specific adaptations to this general schema, called PHR_Schema (see chapter ‎0).

Despite this almost mechanical incitement to adopt a common format for all the interface XML schemas, certain precautions must be taken in order to achieve optimised descriptions.

This is because there is always the option of making the descriptions more or less restrictive. However, lax descriptions take away any benefits to be gained from the checks made possible by the application of the schema. Clearly if all the elements are defined using free text or "anytype", all will be correct but there will then be a large number of possible interpretations, resulting in problems of integration.

The rules for using XML Schema within the context of the PLEIADES interfaces are detailed in chapter 5. Since these rules cannot all be verified simply by checking the validity of the schemas, a checking tool is required. This tool is the PHR Schema Checker.

Care must also be taken to apply the right schema to the right data in order to benefit from the rigour of the definitions during checking. This is a configuration management problem, and one that is all the more easily resolved if the data clearly state the name and the version of their reference schema (see standard heading in chapter ‎5.6).

DOCUMENTATION

While the interface specifications are only validly defined by the XML schemas, it is nevertheless necessary to dispose of a hard copy (html and/or word format) to help understand the data described.

Every XML schema entered into the reference system requires the corresponding documentation to be produced from that same schema.

Because all the schemas comply with the PHR_schema, document production can be automated while guaranteeing complete consistency with the XML schema.

When schemas are changed, the documentation can be very easily updated, however extensive the changes made. The summary of changes relative to the previous version is systematically appended to the document describing the new version of the interface.

This equivalence of content between the XML schema and the documentation obtained from it implies that the documentary attributes are filled. Any additions made directly to the extracted documentation by hand will be lost if changes are made to the schema.

Naming rules and recommendations

Reference system organisation

DIC-1: In order to avoid handling very large XML schemas, the dictionary is divided into a number of sub-dictionaries that are themselves further sub-divided if required. This ensures that the schemas obtained are of reasonable size.

E.g.: base types, geometric types, programming type, etc.

DIC-2: The dictionary contents and the interface descriptions that use them are standardized by using the data characteristics described by the PHR_schema in accordance with [DR1].

E.g.: see ‎6for list of description characteristics used.

Note 1: predefined does not mean unchanging. The list of attributes can be updated if required (omitted characteristic).

Note 2: the attribute names used only serve to standardise the XML files (.xsd and .xml). They can be omitted from the presentation (in Word and/or html format) of the interface description documents if desired. It is therefore the semantic ( i.e. the description) of each attribute that is important, its name serving only to evoke it.

DIC-3: When reusing a standard, the structure of the original data is indicated by means of the SOURCE attribute.

DIC-4: In accordance with the PHR-schema, data characteristics are represented by upper case tags.

E.g.: <DEFINITION> data structure description text </DEFINITION>

Note: the name attribute, which is part of XML, is in lower case

File names

FIC-1: The XML file names (both schemas and data) only use lower case characters without accents. Where applicable, words are separated using an underscore ("_") not a dash ("-").

Justification: upper case characters are sometimes transformed into upper case by PC OSs, in particular accented characters that are not standardised between platforms.

FIC-2: XML schema file names are deduced from the xml root name of their content (matching the case: see FIC 001)

E.g.: phr_orbital_data_predicted.xsd

FIC-3: The files have pre-defined extensions:

.xsd for XML schemas

.xml for XML data

.xsl for XML style sheets

.htm for HTML pages.

FIC-4: All XML file names produced by the Pleiades functional chains are all prefixed with "phr".

E.g.: phr_orbital_data_predicted.xsd

Justification: to avoid any ambiguity in the event of duplication of names between, e.g. a SPOT interface and a PLEIADES interface on the same operational machine.

XML schema writing rules

This chapter specifies certain restrictions that apply to the use of the XML-Schema 2001 standard. These restrictions or rules are intended to:

avoid laxity in the description of the exchanged data,

standardise procedures to simplify the processing of the different project interfaces (in particular to systemise document production),

simplify dictionary management.

Naming rules

SCH-1: All XML schemas state the encoding convention used, i.e. ISO Latin ISO-8859-1

E.g.: <?xml version="1.0" encoding="ISO-8859-1" ?>

Exception: Another encoding will be accepted for reused schemas.

SCH-2: In order to ensure the consistency of the dictionary and the interface descriptions, the name used for each characteristic is that attributed to it in the pre-defined list (see ‎6).

Note: the PHR –Schema specifies the structure and the names used for the documentation information.

SCH-3: The identifiers (data and type elements) are in English.

SCH-4: The XML parsers are protected by encapsulating the text in CDATA tgs if necessary. In any event, any omission will be signalled during the initial XML-Schema analysis.

SCH-5:: A correspondence is established between the name of the xsd file and the schema it contains (see FIC-2)

E.g.: phr_orbital_data_predicted

SCH-6: the data described are named using the most explicit XML identifiers possible. Correspondence with synonyms (necessary abbreviations, name in the original standard, etc.) is ensured by an ‘ALIAS’ attribute (several are allowed).

Note 1: Avoid excessively long names which, while more meaningful, also increase the volume of data exchanged and do not necessarily assist legibility.

Note 2: Thought should be given to the choice of identifiers, in particular to abbreviations (necessary for reducing the volume of data). This process should seek to ensure the consistency of the descriptions. E.g.: Which is preferable PARAMETER or PARAM or P ?

SCH-7: XML identifiers use only upper case characters.

E.g.:

In the schema: <xs:element name="ORBIT" type="A_COUNTER">

In the data: <ORBIT >2304</ORBIT>

SCH-8: The permissible characters for XML identifiers are the letters A to Z, the digits 0 to 9 and the underscore. All identifiers start with a letter.

SCH-9: If transforming an original XML identifier (e.g. taken from a standard), the original name is stored with its original letter case in an ALIAS attribute (noted on the schema).

SCH-10: Where a pre-defined XML base type is available, this should be used in preference to a new definition.

E.g.: <xs:element name="ORBITE_DATATION" type="xs:date">

SCH-11: A type name is formed of an indefinite pronoun followed by a name that makes reference to the class it describes.

E.g.: AN_ORBIT, A_COEFFICIENT etc.…

Exception: the above rule can be waived when reusing a known type.

Justification: there is no obligation to prefix or suffix the names with "TYPE", as there can be no ambiguity between a field name and a type name. When it is defined, the type appears after complexType or simpleType. When it is used, the type name appears after the type attribute.

Example of type name definition:

<xs:complexType name="A_DATE">

Example of type name use:

<xs:element name="START_DATE" type="A_DATE"/>

Data structuring rules

SCH-12: An XML schema describes one, and only one interface (file type or query/result type) by means of a unique root element.

SCH-13: The root element defines the interface: the identifier must be chosen to designate the interface without ambiguity.

SCH-14: The interface consists of a HEADER field (specified in chapter ‎5.6), followed by a SPECIFIC_HEADER field (which, as its name suggests is specific to the interface or to a group of interfaces), which is itself followed by the "useful" data of the interface.

E.g.:

Note: if there is no specific header information, the SPECIFIC_HEADER element is included, but is left blank.

SCH-15: A field is typed (using the XML "xs:type" attribute in the declaration of the element) the moment its definition can potentially be reused. This has the result of making the type available in the dictionary. The definition remains local if the field is an element that is specific to the interface.

SCH-16: The use of collapse is limited to operator-modifiable interfaces. Its use is not recommended for program-generated interfaces (as more permissive).

E.g.:

<xs:element name="U">

<xs:simpleType>

<xs:restriction base="xs:double">

<xs:whiteSpace value="collapse"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Makes the data item <U> 3.14 </U> valid despite the blank character spaces.

SCH-17: The use of patterns is avoided (as they are not very legible and especially because they are very restrictive to use).

SCH-18: Any elements that are to be defined at a later date will be specified as type TBD

E.g.: <xs:element name=" EPHEMERIS" type="base:TBD">

SCH-19: The referencing of a schema implies that there are no TBD or anyType elements remaining in the interface. Similarly, it implies that all elements are defined (either locally or by reference to a type).

SCH-20: A structure (non-terminal field) is defined by a sequence or a choice (sequence or choice but not all).

SCH-21: A structure must always be named.

Justification: a structure groups together elements that form a coherent whole. It must therefore be possible to name this group, which improves legibility.

Consequence: a sequence can only contain elements or choices. A choice can only contain elements.

SCH-22: A terminal field (simpleType) can be defined as a base type (see W3C recommendation for XML-Schema 2001), a base type restriction or a list of simple elements (list).

Justification: the use of list allows a more synthetic data exchange (saving space) while at the same time maintaining control over data types.

E.g.:

<xs:simpleType name="A_CALIBRATION_FUNCTION">

<xs:list itemType="xs:double"/>

</xs:simpleType>

For data: <CALIBRATION_FUNCTION>10.0 5.3 6.2 0.001</CALIBRATION_FUNCTION>

Or else:

<xs:element name="CALIBRATION_FUNCTION">

<xs:complexType>

<xs:sequence maxOccurs="unbounded">

<xs:element name="COEFFICIENT" type="xs:double"/>

</xs:sequence>

</xs:complexType>

</xs:element>

For data:

<CALIBRATION_FUNCTION>

<COEFFICIENT>10.0</COEFFICIENT>

<COEFFICIENT>5.3</COEFFICIENT>

<COEFFICIENT>6.2</COEFFICIENT>

<COEFFICIENT>0.001</COEFFICIENT>

</CALIBRATION_FUNCTION>

SCH-23: A terminal field (simpleType) can also be defined as the combination of a simple type (base type or simple named type) and a single value type.

Justification: for a value to be indicated as being unavailable or out of limits, the value in the interface must inevitably fall outside the data item's valid range. In order for the interface to be validated against its schema, the terminal field must be defined by a union between the data type (together with its valid range) and the exceptional value.

Restrictions

SCH-24: It is forbidden to use the ref attribute in an element declaration.

Justification: for simplicity and consistency, element definitions are limited to a local definition or by reference to a type.

Moreover, the use of ref involves several elements in the schema and it is no longer possible to simply designate the root of the interface.

SCH-25: It is forbidden to use mixed content.

Justification: the interface becomes illegible and unmanageable.

SCH-26: It is forbidden to use all.

Justification: an interface containing unordered data is difficult to manage. Moreover, minOccurs (set to 0) or choice can be used for optional data.

SCH-27: It is forbidden to use redefine.

Justification: it is not sound practice to designate different things by the same name (same type name for different definitions).

SCH-28: It is forbidden to use substitution.

Justification: it is an interoperability feature (outside the Pleiades context).

SCH-29: It is forbidden to use XML attributes.

Justification: there is nothing that clearly justifies using attributes rather than elements. Elements are therefore systematically preferred for the sake of consistency.

Exception: The use of attributes will be tolerated where types are reused that predate the definitions in this document or where the attribute can be shown to have an advantage over the entity in a given case.

SCH-30: It is forbidden to define recursive types

Justification: this is difficult to do in practice and should be strictly limited to cases where no other model is possible.

SCH-31: It is strongly advised not to use unions. Any use must be justified.

Justification: unions make it difficult to check correct typing.

SCH-32: Type specialisation by extension is to be preferred to specialisation by restriction which destroys the link with the original type.

Management rules

SCH-33: Schemas and/or types modified by a functional chain ahead of phase are assigned a local version formed by adding an additional digit to the reference version 2 digit code.

SCH-34: All XML schemas supplied must be accompanied by the hard copies of the documents (html or word format) derived from the schema.

Note: the SCRIBE tool is available to any manager requiring to derive documentation from an XML Schema.

SCH-35: Any new version of an interface supplied must be accompanied by a description of the differences with the previous version.

Note: the ALADIN tool is available for any manager requiring to trace such differences.

SCH-36: XML Schemas must be valid and conform with the rules defined in this document. The reference used to determine the validity of an XML Schema is the diagnostic performed by PHR Schema Checker.

SCH-37: An XML schema must either refer to one or more dictionaries or be self-contained. If it is self-contained, all the types used in the description of the interface are defined locally to the xsd file (referred to as type inlining). The alternative case is a little more complicated, as a distinction is made between types recovered by import and those recovered by include.

A reminder of the conventions used:

An import is associated with a namespace, which is the means of uniquely identifying each of the types of a schema. This makes it possible, for example, to distinguish the type common:date from the type orbit:date (the date defined in the schema common.xsd is different from that defined in the schema orbit.xsd) : the 2 dates can therefore be used in a third schema without ambiguity, as they are prefixed.

An include is a little like using copy and paste to recover type definitions from one schema and insert them into the schema being defined. The notion of namespace does not exist.

By convention, the data exchanged between functional chains are defined using types, these types being declared in the system level dictionaries (base.xsd, common.xsd, orbit.xsd, etc.,)

Data exchanged within a same functional chain are again defined using types, but these types are defined locally in the chain level dictionary. These types are not shared.

Local types are referenced by include, global types are referenced by import. Global types have a targetNamespace but not the local types.

PHR Schema : implementation and use

Configuring XML Spy

The 2004 version of the XML Spy tool can be configured to provide help for creating a new description in XML Schema and for inputting descriptive elements that comply with the list defined in ‎6.

This requires the directory in which the tool is installed to be located (for the remainder of the chapter, it is presumed to be located in "C:\Program Files\Altova"). The tool's configuration files must then either be replaced or added following the procedure described below.

For those writers having access to the CNES Intranet, the reference version of the configuration files are located at:

http://<serveur_operationnel_interfaces_pleiades>/...

Note: the operational server is not known at the date of issuing this document.

First rename "C:\Program
Files\Altova\XMLSPY2004\Schemas\schema\W3C_2001\XMLSchema.xsd" becomes XMLSchemaOrigine.xsd

On the mirage server, click Schema PHR. Next, right-click to save the page under "C:\Program Files\Altova\XMLSPY2004\Schemas\schema\W3C_2001\XMLSchema.xsd".

Still on the mirage server, click phrDoc, then by right-clicking save it under "C:\Program Files\Altova\XMLSPY2004\Schemas\schema\W3C_2001\phrDoc.xsd"

Next click on Template to save the page under "C:\Program Files\Altova\XMLSPY2004\Template\phr.xsd".

The operation is then repeated for the dictionary components (currently base.xsd): they are then viewed on the mirage server and saved under "C:\Program Files\Altova\XMLSPY2004\Template\".

XML Spy is now ready to be used for Pleiades.

Creating a new description in XML Schema

In order to create a new schema for Pleiades using XML Spy, we request the creation of a new "phr" type file (and not "schema" type !). The default extension is "xsd".

We obtain the following description (template):

The first action to be performed is to change the name of the root, which must carry the name of the interface (see SCH-5).

It can then be checked whether the header structure (HEADER field) is defined. If this is not the case, this means that the configuration of XML Spy is incomplete.

The next step consists in specialising the Header. Specialising means selecting an actual value for each element of the Header structure from among the possible values provided by the template. E.g.: the confidentiality level of a file type interface can have 5 possible values (CC, DR, CD, SD or NC), but the confidentiality level for a particular interface type is imposed: this must be specified here (i.e. specialisation). Similarly, certain elements are optional (in the context of a query type interface): we can chose here to delete the elements that will never be present in data of that particular type. We thus obtain a HEADER definition that limits the data producers' options as much as possible, leaving them little more than the data production date to fill in. The advantage of this approach is a better control of the interfaces and fewer errors during the integration of subsystems or functional chains.

Note: XML Spy only allows specialisation to be performed in "Text" or "Grid" display mode.

The next step involves defining the specific header (SPECIFIC_HEADER field) that contains the general information, which is often common to a set of interfaces for a particular chain or sub-system.

Finally, the actual data must be described after the SPECIFIC_HEADER field.

Standard header

This chapter details the standard header.

The header specification is common to all the interfaces of the Pleiades project. However, certain fields of this header are optional so as to take account of the particular characteristics of the interfaces (civilian or defence, file or intra-unit query, etc.). These are described below.

SATELLITE identifies the satellite.

CONFIDENTIALITY is conditional: required for file type interfaces, optional for query or reply type interfaces.

PROVIDER identifies the producer of the data. COUNTRY_ID and CENTER are conditional: i.e. required for file type interfaces. UNIT remains a required field for query or reply type interfaces, but invariably has a value of "AU" for Access Unit.

CONSUMER identifies the n consumers of the interface (file type only).

SCHEMA_REF unambiguously identifies the schema associated with the interface. This enables it to be identified at a glance whether the data structure version is version. Note: the VERSION field is automatically set in the schema at the time of referencing the interface description.

The interface is part of a set of data structures described in an interface document (Word document) referenced in IF_REF.

This common header defines a data structure that must be specialised for each interface type. Caution: specialisation does not mean adulteration. The schema parsers (and in particular le PHR Schema Checker) check that the schema header complies with the common specification.

Inputting descriptive elements

The following schemas which can be accessed from the workstations (on condition that XML Spy has been configured as indicated in chapter ‎5.4) directly implement the desired description of the entities in the XML schemas to be produced.

The ROOT_DOC schema provides the characteristics applying at the root level, i.e., that are valid for all the elements of the current schema.

The DOC schema provides the characteristics applying at the element level, i.e., that are valid for each node or leaf of the current schema.

The MANAGEMENT schema provides the characteristics necessary for managing the configuration.

These three schemas are illustrated on the following pages:

ROOT_DOC schema:

The descriptive element ROOT_DOC attaches to the root of the interface (under xs:annotation and xs:appinfo).

It allows the interface to be described in a pre-established form.

DEFINITION contains the definition of the interface as it is intended to appear in the documentation produced from the schema.

Any comments are added in COMMENT (optional and multiple).

Any illustrations required to explain the interface are contained in ILLUSTRATION.

Finally, an interface is exchanged between a component that produces it and a component that consumes it. This constitutes an EXHANGE. If the interface is consumed by n components, this constitutes an equal number of exchanges that must be described. An EXCHANGE is systematically described by a consumer, a producer, an exchange protocol, etc.

MANAGEMENT schema:

The descriptive element MANAGEMENT describes the different DMs taken into account. This element is necessarily present in the root, but also at any level (field or type) that may justify tracing a modification.

DOC schema:

It is strongly recommended to document the fields and the types of the interface (data elements). The information input must also appear under the descriptive element DOC. The only required field in DOC is DEFINITION, but it is recommended to use the other descriptive elements. Furthermore, in order to obtain documentation that is relevant, it is recommended to use the dedicated rather than the general attributes (e.g.: the unit of a value should be indicated in UNIT rather than COMMENT).

Note : in XML Spy, the descriptive elements (ROOT_DOC, DOC and MANAGEMENT) can only be accessed in "Grid" view mode. (An element is selected and xs:annotation is added in the "elements" menu, under the "add Child" tab, then xs:appinfo and finally phr:ROOT_DOC or phr:DOC or phr:MANAGEMENT according to the case).

Documentation ATTRIBUTE list

All the ATTRIBUTES used to describe the interfaces within the context of the PLEIADES projected are listed below (this list served to define PHR Schema).

This table has been established by applying the attribute identification rules in accordance with the procedure defined in DR1

Attribute (DR1) and Implementation in XML if different
Role
Type of value
Presence and

Condition if applicable

Applicability

Interface

or entities
Uniqueness
Scope
NAME
name	Names the entity described	Identifier	Required	Interface and entities	Unique	Description + data
CLASS

Implicit in XML

XML "types"
XML "elements"	Indicates whether the entity described is a field or a model
No explicitly determined	Entities	Unique
SHORT-DEFINITION

Xs:documentation	Short definition appearing on the screen in the structure decomposition tree	Text	Optional	Entities
Descriptive (MMI)
DEFINITION	Provides the textual definition of the entity described	Text	Required	Interface and entities	Unique	Descriptive
ALIAS	Provides another name under which the entity described is liable to be found and in what context	Identifier and text	Optional	Entities	Multiple	Descriptive
STANDARD	Provides the reference of the standard, the norm or the project from which the entity described originates	Text	Optional	Entities	Unique	Descriptive
COMMENT	Draws attention to a particularity of the entity described	Text	Optional	Interface and entities	Multiple	Descriptive
UNITS	Indicates the units to be used to interpret the numerical value of a field	Text	Conditional

Required for numerical values	Entities	Unique	Descriptive
INHERITS_FROM

pointer from the structure to the XML type	Indicates the model in which the characteristics of a field are described	Identifier	Optional	Entities	Unique	Descriptive
ABBREVIATION	Self-explanatory	Identifier	Optional	Entities	Unique	Descriptive
DEFAULT_VALUE	Default initialisation value of the data item	Of the same type as the data item	Conditional

Required for numerical values	Entities	Unique	Descriptive
NOT_AVAILABLE_VALUE	Value indicating that the data item is not defined	Of the same type as the data item	Conditional

Required for numerical values	Entities	Unique	Descriptive
RANGE
included in the XML type description	Defines the valid range for a numerical entity	2 data type values	Conditional

Required for numerical values	Entities	Unique	Descriptive
ENUMERATION_VALUES
included in the XML type description	Lists the values accepted by the entity	N values	Conditional

Required for numerical values	Entities	Unique	Descriptive
SPECIFIC_INSTANCE	Associate an annotation with a particular value of the valid range	1 data type value plus text	Optional	Entities	Multiple	Descriptive
EXIST_IF	Condition to be verified for the entity described to be included in the data	Text	Optional	Entities	Unique	Descriptive
DECOMPOSITION

sequence.xsd	Names each of the entities into which the entity described breaks down	Identifier	Conditional

Required for structures	Entities	Multiple	Description + data
PRODUCER	Designates the actor(s) responsible for producing data complying with the interface described	Enumerated	Conditional

Required at the root level ( IF)	Interface	Multiple	Descriptive
CONSUMER	Designate the actor(s) receiving data complying with the interface described	Enumerated	Conditional

Required at the root level ( IF)	Interface	Multiple	Descriptive
MANAGEMENT_LEVEL	Designates the level of responsibility associated with the definition of the interface described	Enumerated = Internal, published	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
IMPLEMENTATION_LEVEL	Qualifies the civilian and/or military nature of the interface described	Enumerated = DUAL,

CIVIL,

DEFENCE	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
For each consumer / producer pair

description of the exchange: protocol, volume, validity period, frequency, performance	Descriptive
PROTOCOL	Differentiates file exchanges from message type exchanges (query/result)	Enumerated = FILE, REQUEST	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
VOLUME	Defines the max. volume of data corresponding to an occurrence of the interface described	Value and unit of volume	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
VALIDITY PERIOD	Period of validity of data	Text	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
FREQUENCY

Defines the frequency at which the above volume is delivered	Value and unit of flow	Conditional

Required at the root level ( IF)	Interface	Unique	Descriptive
ILLUSTRATION	Associates an illustration with the entity described	Reference to a file: URL	Optional	Interface and entities	Multiple	Descriptive

Attributes used for managing versions of entities:

Attribute (DR1) and Implementation in XML if different
Role
Type of value
Presence and

Condition if applicable

Applicability

Interface

or entities
Uniqueness
Scope
ISSUE	Memorises the DM and/or FA at the beginning of each version	For each version:
- version identifier
- version date
- list of modifications

( DM/FA reference, text)	Optional	Interface and entities	Multiple	Descriptive

Examples of use of the least intuitive attributes:

SPECIFIC_INSTANCE : (1, "origin of julian days 2000 i.e. 1/1/2000")

EXIST_IF : HEADER.MODE = NOMINAL

An interface is the name given to a data structure exchanged between two partners:

either in the form of a file using a File Transfer Protocol (FTP),

or in the form of queries submitted to a server that implements the expected service offer ("methods").

C N E S
Edit.	:	Date	:
Rév.	:	Date	:
Référence :	Page : 27

REGLES DE REDACTION EN XML SCHEMA

Ce document définit les règles de rédaction des interfaces en XML-Schema pour le projet Pléiades.

XML Schema

PHR-GR-0-2020-CN
DCT/PS/VDO/2005-0245

D. MINGUILLON_DCT/PS/VDO
A. LUCAS_DCT/PS/VDO
B. LARZUL_DCT/PS/VDO

2005-05-12

Laurence Foulon

H. LALANNE_DCT/PS/CMI
G. TESTEMALE_DCT/PS/SSC
S. BAILLARIN_DCT/PS/TIS
M. PORTAL_DCT/PO/OH

CNES