Code Gen Failures (RTIDDSGEN) with NATO XSD (STANAG 5527)

7 posts / 0 new
Last post
Offline
Last seen: 12 years 6 months ago
Joined: 05/25/2012
Posts: 1
Code Gen Failures (RTIDDSGEN) with NATO XSD (STANAG 5527)

Hello,

 

I am trying to use rtiddsgen to create java code from the NATO XSD from STANAG 5527.  I have included the XSD we are using below.

 

We are getting the following errors, and do not know why:

 

 

Running rtiddsgen version 4.5f, please wait ...

C:\Users\DEVELO~1\AppData\Local\Temp\rtiddsnffi_stanag5527.xsd18137modulesxsd.xml:88 The content of element type "types" must match "(include|const|directive|struct|valuetype|union|typedef|module|enum|forward_dcl)+".

Done (failures)

 

 

XSD:

 

 

<?xml version="1.0" encoding="UTF-8"?>

<!-- edited with XMLSpy v2007 sp2 (http://www.altova.com) by NC3A (NC3A) -->

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="urn:nato:fft:protocols:nffi14" targetNamespace="urn:nato:fft:protocols:nffi14"

elementFormDefault="qualified" xml:lang="en">

<xsd:annotation>

<xsd:documentation>The schema defines a layout for the NATO Friendly

Force Identification (NFFI) XML message format. This message is used

to exchange track information between NATO and national Force

Tracking System (FTS).

Version: NFFI 1.4

</xsd:documentation>

</xsd:annotation>

<!---->

<xsd:element name="NFFIMessage">

<xsd:annotation>

<xsd:documentation>Purpose: provides track data.

Format: A single NFFI message can be empty (no track information). The

track data is provided in 'track' element of type 'trackType'. The

number of elements in a single NFFI message is unbounded.

</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="track" type="trackType" minOccurs="0"

maxOccurs="unbounded" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Track type definition ******************************************************************************* 

******************************************************************************* -->

<xsd:complexType name="trackType">

<xsd:annotation>

<xsd:documentation>Purpose: Provides data related to a track. The

data is divided into five sections - positional data

('positionalData' element), unit identification data

('identificationData' element), unit operational status data

('operStatusData' element), device specific data

('deviceSpecificData' element), and non-standard detailed data

('detailData'). A single track can be uniquely identified by a

combination of values in 'trackSource' and 'dateTime' elements from

'positionalData' section.

Format: A single track contains one and only one 'positionalData' element.

It is a mandatory element. All the other elements, i.e.

'identificationData', 'operStatusData', 'deviceSpecificData', and

'detailData' are optional.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="positionalData" type="positionalDataType" />

<xsd:element name="identificationData" type="identificationDataType"

minOccurs="0" />

<xsd:element name="operStatusData" type="operStatusDataType"

minOccurs="0" />

<xsd:element name="detailData" type="detailDataType"

minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Positional data type definition ******************************************************************************* 

******************************************************************************* -->

<xsd:complexType name="positionalDataType">

<xsd:annotation>

<xsd:documentation>Purpose: section of positional and track

identification data. Defines a structure of 'positionalData'

element, which is a mandatory field in an element of 'trackType'

type.

Format: Contains a set of elements which all together constitute positional

data. as well as a set attributes for security labeling. Every

element type is defined separately.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<!---->

<xsd:element name="trackSource" type="trackSourceType" />

<!---->

<xsd:element name="dateTime" type="dateTimeType" />

<!---->

<xsd:element name="coordinates" type="coordinatesType" />

<!---->

<xsd:element name="bearing" minOccurs="0">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="bearingType">

<xsd:attribute name="accuracy" type="bearingAccuracyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

<xsd:element name="speed" minOccurs="0">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="speedType">

<xsd:attribute name="accuracy" type="speedAccuracyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

<xsd:element name="reliability" type="reliabilityType"

minOccurs="0" />

<!---->

<xsd:element name="inclination" minOccurs="0">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="inclinationType">

<xsd:attribute name="accuracy" type="inclinationAccuacyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

</xsd:sequence>

<xsd:attribute name="secPolicyName" type="secPolicyNameType" />

<xsd:attribute name="secClassification" type="secClassificationType" />

<xsd:attribute name="secCategory" type="secCategoryType" />

<!---->

</xsd:complexType>

<!-- ******************************************************************************* 

*****Definition of types of elements being used in *****'positionalDataType' 

******************************************************************************* -->

<!-- ******Track ID type definition -->

<xsd:complexType name="trackSourceType">

<xsd:annotation>

<xsd:documentation>Purpose: unambiguous identification of data

source.

Format: contains a value being a combination of data on the device that

transmitted the data and the system which releases the data. The

value has to be unique for every device/system in order to

unambiguously identify the source of information.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="sourceSystem" type="sourceSystemType" />

<xsd:element name="transponderId" type="transponderIdType" />

</xsd:sequence>

</xsd:complexType>

<!-- ******System source type definition -->

<xsd:complexType name="sourceSystemType">

<xsd:annotation>

<xsd:documentation>Purpose: track data source identification.

Format: identifies track data owner/producer (system that releases the

data, country (optional) which controls the system and sub-system

(optional)). Only the system value is used for unique

identification.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="country" type="countryType" minOccurs="0" />

<xsd:element name="system" type="systemType" />

<xsd:element name="subsystem" type="systemType"

minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

<!-- ******Country type definition -->

<xsd:simpleType name="countryType">

<xsd:annotation>

<xsd:documentation>Purpose: National allegiance of the track data

source.

Format: String of ISO 3166-1 three letter-codes. Full list of values is in

STANAG 1059 ed.8.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:pattern value="[A-Z]{3}" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******System identyfier type definition -->

<xsd:simpleType name="systemType">

<xsd:annotation>

<xsd:documentation>Purpose: Identification of the system which

releases data.

Format: string of up to 30 characters. Following characters are

permissible: [A-Z], [a-z], [0-9], period, comma, colon, asterisk,

and dash.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="30" />

<xsd:pattern value="([A-Z0-9\-])*" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Tracking device ID type definition -->

<xsd:simpleType name="transponderIdType">

<xsd:annotation>

<xsd:documentation>Purpose: Data transmitting device identification /

originator identification.

Format: String of up to 60 characters. Following characters are

permissible: [A-Z], [a-z], [0-9], period, comma, colon, asterisk,

and dash.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:minLength value="1" />

<xsd:maxLength value="60" />

<xsd:pattern value="([A-Za-z0-9\.,:\*\-])*" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Date/Time type definition -->

<xsd:simpleType name="dateTimeType">

<xsd:annotation>

<xsd:documentation>Purpose: Effective date and time that are referred

to UTC time (see Reference : C2IEDM v 6.15a).

Format: ISO 8601 for date and time representation in the format

YYYYMMDDhhmmss format (14 digits)

YYYY = YEAR (4 digits),

MM = MONTH (2 digits),

DD = DAY (2 digits),

hh = HOUR (2 digits),

mm = MINUTE (2 digits),

ss = SECOND (2 digits).

Example :"05 of March 2005, 09 h 10 m 23 s" = 20050305091023.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:pattern value="\d{14}" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Coordinates type definition -->

<xsd:complexType name="coordinatesType">

<xsd:annotation>

<xsd:documentation>Purpose: object coordinates.

Format: 2/3D geographical coordinates including latitude and longitude

(mandatory) and altitude (optional).

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<!---->

<xsd:element name="latitude">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="latitudeType">

<xsd:attribute name="accuracy" type="horizontalAccuracyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

<xsd:element name="longitude">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="longitudeType">

<xsd:attribute name="accuracy" type="horizontalAccuracyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

<xsd:element name="altitude" minOccurs="0">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="altitudeType">

<xsd:attribute name="accuracy" type="altitudeAccuracyType" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

<!---->

</xsd:sequence>

</xsd:complexType>

<!-- ******Latitude type definition -->

<xsd:simpleType name="latitudeType">

<xsd:annotation>

<xsd:documentation>Purpose: Angular distance north or south of the

earth's equator (see Reference ): WGS 84).

Format: Numeric data in range including -90, 90. Value in decimal degrees.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="-90" />

<xsd:maxInclusive value="90" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Longitude type definition -->

<xsd:simpleType name="longitudeType">

<xsd:annotation>

<xsd:documentation>Purpose: Angular distance on the earth's surface,

measured east or west from the prime meridian at Greenwich, England

(see Reference : WGS 84).

Format: Numeric data in range excluding -180, including 180. Value in

decimal degrees.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minExclusive value="-180" />

<xsd:maxInclusive value="180" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Altitude type definition -->

<xsd:simpleType name="altitudeType">

<xsd:annotation>

<xsd:documentation>Purpose: The vertical distance of a level, a point

or an object considered as a point, measured from mean sea level

(see Reference : AAP-6(2006)).

Format: Numeric data in meters msl.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:double" />

</xsd:simpleType>

<!-- ******Bearing type definition -->

<xsd:simpleType name="bearingType">

<xsd:annotation>

<xsd:documentation>Purpose: The rotational measurement clockwise from

the line of true North to the direction of motion of a specific

track (see References : C2IEDM v 6.15e, JC3IEDM ed.3, US BFT COI EIS

v.0.1).

Format: Numeric representation in range including 0 and excluding 360 of

the bearing value in decimal degree.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

<xsd:maxExclusive value="360" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Speed type definition -->

<xsd:simpleType name="speedType">

<xsd:annotation>

<xsd:documentation>Purpose: Speed value of the platform that holds

the tracking device.

Format: Numeric representation of the speed value in Km per hours.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Inclination type definition -->

<xsd:simpleType name="inclinationType">

<xsd:annotation>

<xsd:documentation>Purpose: The rotational measurement from the

horizontal plane to the direction of motion of a specific

battlespace object at a specific location where the positive angle

is vertically upward (see References : JC3IEDM ed.3 and US BFT COI

EIS v.0.1).

Format: Numeric representation in range including 0, excluding 360. Value

in decimal degrees.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

<xsd:maxExclusive value="360" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Reliability type definition -->

<xsd:simpleType name="reliabilityType">

<xsd:annotation>

<xsd:documentation>Purpose: the specific value that represents (for

intelligence purpose) the general appraisal of the source in graded

terms to indicate the extent to which it has been proven it can be

counted on or trusted in to do as expected (see References : C2IEDM

v 6.15e, JC3IEDM ed.3).

Format: Following values are permissible: “COMPLETELY RELIABLE”, “USUALLY

RELIABLE”, “ FAIRLY RELIABLE”, “NOT USUALLY RELIABLE”, “UNRELIABLE”,

“RELIABILITY CANNOT BE JUDGED”.

Example: For FFT this could refer, for instance, to reported units of combat

id sensing.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="COMPLETELY_RELIABLE" />

<xsd:enumeration value="USUALLY_RELIABLE" />

<xsd:enumeration value="FAIRLY_RELIABLE" />

<xsd:enumeration value="NOT_USUALLY_RELIABLE" />

<xsd:enumeration value="UNRELIABLE" />

<xsd:enumeration value="RELIABILITY_CANNOT_BE_JUDGED" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Horizontal accuracy type definition -->

<xsd:simpleType name="horizontalAccuracyType">

<xsd:annotation>

<xsd:documentation>Purpose: The one-dimensional linear distance

representing the uncertainty in the horizontal plane in terms of

probable circular error for a battlespace object. E.g. usually in

GPS devices it is a single value which refers to a location of an

absolute point described by longitude and latitude (see References :

JC3IEDM ed.3 and US BFT COI EIS v.0.1).

Format: A non-negative numerical value in meters.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Altitude accuracy type definition -->

<xsd:simpleType name="altitudeAccuracyType">

<xsd:annotation>

<xsd:documentation>Purpose: The one-dimensional linear distance

representing the uncertainty in terms of probable error range for

the vertical axis of a battlespace object (see References : JC3IEDM

ed.3 and US BFT COI EIS v 0.1).

Format: A non-negative numeric value in metres.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Bearing accuracy type definition -->

<xsd:simpleType name="bearingAccuracyType">

<xsd:annotation>

<xsd:documentation>Purpose: The rotational measurement of a sector

that represents the uncertainty range in the estimate of the bearing

at a specific location. The sector is bisected by the bearing (see

References : C2IEDM v 6.15e, JC3IEDM ed.3 and US BFT COI EIS v.0.1).

Format: a non-negative numeric value in range up to and excluding

360. It represents units of degrees.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

<xsd:maxExclusive value="360" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Speed accuracy type definition -->

<xsd:simpleType name="speedAccuracyType">

<xsd:annotation>

<xsd:documentation>Purpose: The numeric value that denotes the

uncertainty range in the estimate for the speed at a specific

location where the speed estimate falls at the centre of the

accuracy range (see References : C2IEDM v 6.15e, JC3IEDM ed.3 and US

BFT COI EIS v.0.1)

Format: a non-negative numeric value in kilometres per hour.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

<xsd:maxExclusive value="10000" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Inclination accuracy type definition -->

<xsd:simpleType name="inclinationAccuacyType">

<xsd:annotation>

<xsd:documentation>Purpose: The rotational measurement of a vertical

sector that represents the uncertainty range in the estimate of the

inclination at a specific location. The sector is bisected by the

inclination (see References : JC3IEDM ed.3 and US BFT COI EIS

v.0.1).

Format: A non-negative numeric value in range up to and excluding 360. It

represents units of degrees.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

<xsd:maxExclusive value="360" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Unit identification type definition ******************************************************************************* 

******************************************************************************* -->

<xsd:complexType name="identificationDataType">

<xsd:annotation>

<xsd:documentation>Purpose: identification of the unit that is

associated with data in the 'positionalData' section. Usually needed

for a standard situation display.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name="unitSymbol" type="unitSymbolType" />

<xsd:element name="unitShortName" type="unitShortNameType"

minOccurs="0" />

</xsd:sequence>

<xsd:attribute name="secPolicyName" type="secPolicyNameType" />

<xsd:attribute name="secClassification" type="secClassificationType" />

<xsd:attribute name="secCategory" type="secCategoryType" />

</xsd:complexType>

<!-- ******************************************************************************* 

*****Definition of types of elements being used in *****'identificationType' 

******************************************************************************* -->

<!-- ******Unit symbol type definition -->

<xsd:simpleType name="unitSymbolType">

<xsd:annotation>

<xsd:documentation>Purpose: Unit (graphical) symbol ID

Format: String of fifteen characters ([A-Z], [0-9], dash) as specified in

APP-6(A), Annex B - Symbol Id Coding.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:pattern value="[A-Z0-9\-]{15}" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Unit short name type definition -->

<xsd:simpleType name="unitShortNameType">

<xsd:annotation>

<xsd:documentation>Purpose: (short) Unit designator.

Format: Free text, possibly following agreed naming conventions, up to 21

characters. If also 'unitSymbol' is specified, the designator need

only be unique within the country specified in the 'unitSymbol'.

Following characters are permissible: [A-Z], [a-z], [0-9], period,

comma, colon, asterisk, dash and space. Reference for format :

APP-6(A), 505 Symbol Modifiers.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:minLength value="1" />

<xsd:maxLength value="21" />

<xsd:pattern value="([A-Za-z0-9\.,:\*\- ])*" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Operational status data type definition ******************************************************************************* 

******************************************************************************* -->

<xsd:complexType name="operStatusDataType">

<xsd:annotation>

<xsd:documentation>Purpose: provides information on operational

status of the unit associated with data in 'positionalData' section.

Format: All elements of the section are optional.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<!---->

<xsd:element name="footprint" type="footprintType"

minOccurs="0" />

<xsd:element name="strength" type="strengthType"

minOccurs="0" />

<xsd:element name="statusCode" type="statusCodeType"

minOccurs="0" />

<xsd:element name="alert" type="alertType" minOccurs="0" />

<xsd:element name="remarks" type="remarksType" minOccurs="0"

maxOccurs="4" />

</xsd:sequence>

<xsd:attribute name="secPolicyName" type="secPolicyNameType" />

<xsd:attribute name="secClassification" type="secClassificationType" />

<xsd:attribute name="secCategory" type="secCategoryType" />

</xsd:complexType>

<!-- ******Footprint type definition -->

<xsd:simpleType name="footprintType">

<xsd:annotation>

<xsd:documentation>Purpose: Radius of a circular area in which the

represented unit operates, measured from the centre as specified by

‘coordinates.latitude’ and ‘coordinates.longitude’ elements.

Format: Numeric representation of the unit coverage value in meters.

</xsd:documentation>

</xsd:annotation>

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

<xsd:minInclusive value="0" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Strength type definition -->

<xsd:simpleType name="strengthType">

<xsd:annotation>

<xsd:documentation>Purpose: Number of vehicles represented by the

track.

Format: Numeric data in range including 0 up to 65535.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:unsignedShort" />

</xsd:simpleType>

<!-- ******Status type definition -->

<xsd:simpleType name="statusCodeType">

<xsd:annotation>

<xsd:documentation>Purpose: The specific value that represents the

operational status of the represented unit (see Reference :

AAP-6(2006) (Operational Readiness)).

Format: Following values are permissible: "OPERATIONAL", "SUBSTANTIALLY

OPERATIONAL", "MARGINALLY OPERATIONAL", "TEMPORARILY NOT

OPERATIONAL", "NOT OPERATIONAL", "NOT KNOWN".

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="OPERATIONAL" />

<xsd:enumeration value="SUBSTANTIALLY_OPERATIONAL" />

<xsd:enumeration value="MARGINALLY_OPERATIONAL" />

<xsd:enumeration value="TEMPORARILY_NOT_OPERATIONAL" />

<xsd:enumeration value="NOT_OPERATIONAL" />

<xsd:enumeration value="NOT_KNOWN" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Alert type definition -->

<xsd:simpleType name="alertType">

<xsd:annotation>

<xsd:documentation>Purpose: Emergency state. In general, it is an

emergency not only sent before destruction of the FTS equipment.

Format: Boolean value representing the emergency state. The value is

TRUE if the device is in the emergency state. The detailed nature of

the emergency can be explained in “remark” field.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:boolean" />

</xsd:simpleType>

<!-- ******Remarks type definition -->

<xsd:simpleType name="remarksType">

<xsd:annotation>

<xsd:documentation>Purpose: Additional remarks on the track

Format: Free text up to 60 characters. Following characters are

permissible: [A-Z], [a-z], [0-9], period, comma, colon, asterisk,

dash and space.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="60" />

<xsd:pattern value="([A-Za-z0-9\.,:\*\- ])*" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Detail type definition ******************************************************************************* 

******************************************************************************* -->

<xsd:complexType name="detailDataType">

<xsd:annotation>

<xsd:documentation>Purpose: Gives some flexibility in the future

addition of extensions to the message definition. It can be used to

include specific ad hoc requirements and/or to carry information

that is specific to smaller communities of producers and consumers

and require more intimate knowledge of the operating domain.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:any processContents="skip" minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

<xsd:attribute name="secPolicyName" type="secPolicyNameType" />

<xsd:attribute name="secClassification" type="secClassificationType" />

<xsd:attribute name="secCategory" type="secCategoryType" />

<xsd:anyAttribute processContents="skip" />

</xsd:complexType>

<!-- ******************************************************************************* 

******************************************************************************* 

*****Security layer types definition ******************************************************************************* 

******************************************************************************* 

*****Identified security layer types are in line with security related *****fields 

specified in "GUIDANCE ON THE USE OF METADATA *****ELEMENT DESCRIPTIONS FOR 

USE IN THE NATO DISCOVERY *****METADATA SPECIFICATION (NDMS)" *****Reference 

EAPC(AC/322-SC/5)N(2006)0008 ******************************************************************************* -->

<!-- ******Security policy name type -->

<xsd:simpleType name="secPolicyNameType">

<xsd:annotation>

<xsd:documentation>Purpose: Identify the nation or organization

responsible for creating, maintaining, and implementing the security

policy to be applied to the information. The security policy is

understood as a set of rules for protecting information against

unauthorized discloser, while maintaining authorised access, and

preventing loss of unauthorized modification. The policy bodies of

different security domains must agree on a common understanding of

the

handling requirements for information of a particular sensitivity. After the

understanding exists, mappings from one security policy to another

can be created (see Reference EAPC(AC/322-SC/5)N(2006)0008).

Format: Free text up to 50 characters.

Example: NATO, NATO/EAPC, NATO/PFP, NATO/EU, NATO/RUSSIA, NATO/UKRAINE.

National use includes: USA, FRA, GBR, NLD, etc.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="256" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Security classification type -->

<xsd:simpleType name="secClassificationType">

<xsd:annotation>

<xsd:documentation>Purpose: Security markings that indicate the

sensitivity level of the information (see Reference :

EAPC(AC/322-SC/5)N(2006)0008).

Format: Free text of up to 30 characters.

Example: as defined in AC/322-D(2004)0021 and in "Guidance on the use of

metadata element descriptions for use in NDMS": UNMARKED,

UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, and COSMIC TOP

SECRET.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:minLength value="1" />

<xsd:maxLength value="30" />

</xsd:restriction>

</xsd:simpleType>

<!-- ******Security category type -->

<xsd:simpleType name="secCategoryType">

<xsd:annotation>

<xsd:documentation>Purpose: Indication of an additional, specific

sensitivity, or a dissemination control, or an informational marking

on which no automated access control is performed (see Reference :

EAPC(AC/322-SC/5)N(2006)0008).

Format: string of up to 256 characters.

Examples: special category designator include ATOMAL, CRYPTO, SIOP, SIOP ESI.

Dissemination Limitation Markings include EXCLUSIVE, INTELLIGENCE,

LOGISTICS, OPERATIONS. Release categories include RELEASABLE TO,

RELEASABLE FOR (e.g. RELEASABLE TO ISAF or RELEASABLE FOR INTERNET

TRANSMISSION). Administrative markings include MANAGEMENT, STAFF,

PERSONAL, MEDICAL, COMMERCIAL.

</xsd:documentation>

</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:maxLength value="256" />

</xsd:restriction>

</xsd:simpleType>

</xsd:schema>

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 1 min ago
Joined: 06/02/2010
Posts: 602

 

Text added on 11-05-2012:   The original answer I posted below is not correct. As it turns out the problem was in some of the constructs used in the XSD which were not properly understood by rtiddsgen. Please scroll down to my second posting to this thread titled: "Solution to Code Gen Failures (RTIDDSGEN) with NATO XSD" for the correct resolution to this issue.

The original (incorrect) posting from 06-02-2012 follows below.

----

Hi,

Can you post the command-line options that you are using when running rtiddsgen?

I suspect to fix the problem you need to use the command line option "-inputXsd" instead of what you are doing now. However read below for more details and caveats.

In addition to IDL files, rtiddsgen can process files that describe types using XML an also using XSD. Note that even it technically and XSD document is a special form of an XML document. The way types are described to rtiddsgen when using XML is different from the format when using XSD.

To indicate to rtiddsgen that you want to process an XSD file you need to pass the additional parameters  "-inputXsd". If you want to pass an file with types described using the XML format, then you would use "-inputXml".  

From your errors I would suspect you are using "-inputXml" because the keywords that appear in the error message: "include|const|directive|struct|valuetype|union|typedef|module|enum|forward_dcl" are precisely the ones expected in an XML document, not in an XSD document. So using "-inputXsd" instead might solve your problem.

That said I am not sure if the processing of the XSD you have will succeeds of if you will need to do a few tweaks. The issue is that rtiddsgen supports only a subset of the types that are describable using the XSD language. If you are using types unsupported by rtiddsgen, then you will get some errors.

Let us know how that goes.

Gerardo

Offline
Last seen: 12 years 4 days ago
Joined: 10/30/2012
Posts: 2

Hi there,

I am also experiencing the same issue with the NFFI_13.xsd schema file. I am using the following command line arguments to rtiddsgen, and have downloaded the latest version 5.0 just today.

 

C:\Program Files (x86)\RTI>rtiddsgen -language Java -convertToIdl -verbosity 3 -inputXsd NFFI_13.xsd

The above returns the following command line response:

 

Running rtiddsgen version 5.0.0, please wait ...

Warning: The DTD file '/C:/Program%20Files%20(x86)/RTI/ndds.5.0.0/scripts/../resource/rtiddsgen/schema/rti_dds_topic_types.dtd' does not exist. rtiddsgen will use the default DTD located under 'C:/Program Files (x86)/RTI/ndds.5.0.0/scripts/../resource/rtiddsgen/schema/rti_dds_topic_types.dtd'

C:\Users\Rob\AppData\Local\Temp\rtiddsNFFI_13.xsd63885modulesxsd.xml:109 The content of element type "types" must match "include|const|directive|struct|valuetype|union|typedef|module|enum|bitset|forward_dcl)+".

C:\Users\Rob\AppData\Local\Temp\rtiddsNFFI_13.xsd63885modulesxsd.xml:109 The content of element type "types" must match (include|const|directive|struct|valuetype|union|typedef|module|enum|bitset|forward_dcl)+".

Done (failures)

The referenced element type "types" does not exist in the NFFI_13.xsd but rather in the rti_dds_topic_types.dtd - 1st line in fact. The error would therefore suggest that rtiddsgen has a problem with this file rather than the provided XSD?? 

Note: I am using windows 7 ultimate. I opened a command prompt using the link under RTI Connext 5.0.0. I then ran rti_set_env_5.0.0.bat, and vcvars32.bat to ensure environment variables were correct, and then ran rtiddsgen.

Can anyone help me with this?

Regards

Rob

 

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 1 min ago
Joined: 06/02/2010
Posts: 602

 

Hello Rob,

I do not have direct access to the NATO  STANAG 5527 so I am I not sure if I used the correct one.  I created the STANAG5527_NFFI14.xsd file from what ajconnol posted to this thread.  This appears to be NFFI version 1.4 whereas you mentioned 1.3.  I did not look at the 1.3 version but it is likely the problems are similar.

In the end I identified a few issues with the XSD and was able to modify it to get it to compile. For this I had to do three main changes:

  1. Remove the first annotation in the XSD which appears directly under the <xsd:schema> tag.
  2. Reorder the XSD so that types are declared before they are used
  3. Modify any XSD types that declare "attributes" replacing those with equivalent types that only use elements

I have attached to this reply (see at the bottom) both the the modified XSD (STANAG5527_NFFI14.xsd) as well as original one (STANAG5527_NFFI14_original.xsd). I describe here the steps I took in detail because I think it can be helpful in trouble-shooting similar problems.

I used RTI Connext DDS version 5.0.0 on Windows XP. However the results should be the similar on other platforms and when I run the rtiddsgen  command I get the same error you and ajconnol reported:

 

Z:\examples\nato_stanag5527_nffi> rtiddsgen.bat  -ppDisable -language C++ -namespace -replace -example i86Win32VS2008  STANAG5527_NFFI14.xsd
[11/03/12 12:29:58] Executing: "Z:\dom\apps_rti\RTI500_win32\ndds.5.0.0\scripts\rtiddsgen.bat" -pauseAtEnd  -ppDisable -language C++ STANAG5527_NFFI14.xsd
C:\DOCUME~1\gerardo\LOCALS~1\Temp\rtiddsSTANAG5527_NFFI14.xsd52889modulesxsd.xml:93 The content of element type "types" must match "(include|const|directive|struct|valuetype|union|typedef|module|enum|bitset|forward_dcl)+".
C:\DOCUME~1\gerardo\LOCALS~1\Temp\rtiddsSTANAG5527_NFFI14.xsd52889modulesxsd.xml:93 The content of element type "types" must match "(include|const|directive|struct|valuet ype|union|typedef|module|enum|bitset|forward_dcl)+".
Done (failures)

 

The error printed is not clear but it is caused by the presence of the <xsd:annotation> in line 6, that is, directly inside the <xsd:schema> element. The DTD used by rtiddsgen is not accepting this and is complaining that it expects only one of the tags:  include, const, directive, struct, valuetype, union, typedef, module, enum, bitset, or forward_dcl

The error is confusing. The problem is that internally rtiddsgen transforms the XSD file to an intermediate XML representation and it reports the errors on that file, not the original XSD file.  As a consequence it incorrectly reports the error as affecting the <types> element (which is the root element in the transformed XML file), instead of  reporting it affects the <xsd:schema> element which is the root in the XSD.  Furthermore it reports line number 93 in the XML instead of 6 in the XSD.  

If you comment-out this XSD annotation, rtiddsgen will l complete and generate the header files. However it still reports some errors:

Z:\examples\nato_stanag5527_nffi> rtiddsgen.bat  -ppDisable -language C++ -namespace -replace -example i86Win32VS2008  STANAG5527_NFFI14.xsd
Running rtiddsgen version 5.0.0, please wait ...
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78;org.xml.sax.SAXException: 1:1:unexpected token: null
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78; org.xml.sax.SAXException: 1:1:unexpected token: null
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78; org.xml.sax.SAXException: 1:1:unexpected token: null
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78; org.xml.sax.SAXException: 1:1:unexpected token: null
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78; org.xml.sax.SAXException: 1:1:unexpected token: null
file:///Z:/dom/apps_rti/RTI500_win32/ndds.5.0.0/scripts/../resource/rtiddsgen/xml/xmlRawTransform.xsl; Line #852; Column #78; org.xml.sax.SAXException: 1:1:unexpected token: null
Done
 
The header files, examples and projects are generated. But the compilation gives many errors when compiling the header file that contins the generated data-types:
 
 
1>z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(61) : error C2146: syntax error : missing ';' before identifier 'positionalData'
1>z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
 
And many others...
What happens is that in the XSD some of the types are used as elements of other types before being defined later in the file. This is OK in an XSD, but it does not work in languages such as C++ where a type must be declared before being used.  
 
 
I reorganized the order of the declarations in the XSD so types are declared before being used. After doing this I re-run rtiddsgen -replace ...  and tried to compile again the example code.  This still gave a lot fewer errors:
 
 
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(787) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(789) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(791) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1707) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1709) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1713) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1807) : error C2146: syntax error : missing ';' before identifier 'detailData'
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1807) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(1807) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1
Looking at the header file we see that the error in lines 787-791 correspond to the declaration of class coordinatesType  copied below. We can see the members 'latitude', 'longitude', and 'altitude'. Are lacking a data-type.  The error in line 1707-1713 is similar.
 
 
 
class coordinatesType                                        
{
public:            
#ifdef __cplusplus
    typedef struct coordinatesTypeSeq Seq;
 
#ifndef NDDS_STANDALONE_TYPE
    typedef coordinatesTypeTypeSupport TypeSupport;
    typedef coordinatesTypeDataWriter DataWriter;
    typedef coordinatesTypeDataReader DataReader;
#endif
 
#endif
    
      latitude;
 
      longitude;
 
      altitude;  
};  
Looking at the file XSD section that defines coordinatesType we see the declaration of latitude as:
 
<xsd:complexType name="coordinatesType">
             ...
<xsd:element name="latitude">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="latitudeType">
<xsd:attribute name="accuracy" type="horizontalAccuracyType" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
            ...
</xsd:complexType>
 
The problem is that this is defining the schema for XML documents that contain attributes, in this case "accuracy" so that the corresponding XML would look similar to this:
 
<latitude  accuracy="3.5">34.5</latitude>
This kind of type declaration is not supported by rtiddsgen because when it gets mapped to the different programming languages there is no direct way to express the attributes. For this reason rtiddsgen expects and XSD where the elements have no attributes.
Unfortunately this cannot be fixed without changing the XSD in a way that it will not validate prior documents.  For example I made the change to:
<xsd:complexType name="latitudeWithAccuracyType">
<xsd:sequence>
<xsd:element name="value" type="latitudeType" minOccurs="1" maxOccurs="1"/>
<xsd:element name="accuracy" type="horizontalAccuracyType" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
 
 
<xsd:complexType name="coordinatesType">
             ...
<xsd:element name="latitude">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="latitudeType">
<xsd:attribute name="accuracy" type="horizontalAccuracyType" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
           ...
</xsd:complexType>
This is semantically equivalent, but will not validate the exact same XML documents. The XML will now have to be written as:
       <latitude><accuracy>3.5</accuracy><value>34.5</value></latitude>
Note that there is perhaps a better way to do this. I would need to investigate it more...
I applied this change to the definition of the following members:
     coordinatesType  members:  latitude,  longitude,  altitude 
     positionalDataType members:   bearing,  speed,  inclination
After this change when I re-run rtiddsgen I no longer had any of the previous error messages regarding the SAXException in the xmlRawTransform.xsl
 
 
 
Z:\examples\nato_stanag5527_nffi> rtiddsgen.bat -replace  STANAG5527_NFFI14.xsd
Running rtiddsgen version 5.0.0, please wait ...
Done
These changes solved some of the previous compilation errors but other errors still remain:
 
 
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(2347) : error C2146: syntax error : missing ';' before identifier 'detailData'
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(2347) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Z:\examples\nato_stanag5527_nffi\STANAG5527_NFFI14.h(2347) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
Looking at the STANAG5527_NFFI14.h header file I saw the the type declaration for the type detailDataType is missing. This is the data-type for the member 'detailData' on the reported error line number.
 
 
Looking at the declaration for the element 'detailedDataType' in XSD we can see that it defines attributes which as we mentioned are not supported by rtiddsgen:
 
 
<xsd:complexType name="detailDataType">
<xsd:annotation>
<xsd:documentation>
Purpose: Gives some flexibility in the future
addition of extensions to the message definition. It can be used to
include specific ad hoc requirements and/or to carry information
that is specific to smaller communities of producers and consumers
and require more intimate knowledge of the operating domain.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:any processContents="skip" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
 
<xsd:attribute name="secPolicyName" type="secPolicyNameType" />
<xsd:attribute name="secClassification" type="secClassificationType" />
<xsd:attribute name="secCategory" type="secCategoryType" />
<xsd:anyAttribute processContents="skip" />
</xsd:complexType>
I modified the type declaration to use elements instead of attributes. I also removed commented out the use of the xsd:any and xsd:anyAttribute as this are extensibility mechanism in the XSD language intended to allow validation of document with extra elements but do not indicate any actual attributes. 
 
 
The modified definition is:
 
<xsd:complexType name="detailDataType">
<xsd:annotation>
<xsd:documentation>
Purpose: Gives some flexibility in the future
addition of extensions to the message definition. It can be used to
include specific ad hoc requirements and/or to carry information
that is specific to smaller communities of producers and consumers
and require more intimate knowledge of the operating domain.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="secPolicyName" type="secPolicyNameType" />
<xsd:element name="secClassification" type="secClassificationType" />
<xsd:element name="secCategory" type="secCategoryType" />
</xsd:sequence>
</xsd:complexType>
With this changes I was able to compile the example code against the RTI Connext DDS libraries and run the example code generated by rtiddsgen.
 
I did not inspect the output in detail comparing it with the STANAG5527_NFFI14.xsd but from a first look it seems OK.
 
 
 
Z:\examples\nato_stanag5527_nffi>.\objs\i86Win32VS2008\STANAG5527_NFFI14_publisher.exe
Writing trackType, count 0
Writing trackType, count 1
Writing trackType, count 2

 

Z:\examples\nato_stanag5527_nffi>.\objs\i86Win32VS2008\STANAG5527_NFFI14_subscriber.exe
trackType subscriber sleeping for 4 sec...
 
   positionalData:
      trackSource:
         sourceSystem:
            country:
               : ""
            system:
               : ""
            subsystem:
               : ""
         transponderId:
            : ""
      dateTime:
         : ""
      coordinates:
         latitude:
            value:
               : 0.000000
            accuracy:
               : 0.000000
         longitude:
            value:
               : 0.000000
            accuracy:
               : 0.000000
         altitude:
            value:
               : 0.000000
            accuracy:
               : 0.000000
      bearing:
         value:
            : 0.000000
         accuracy:
            : 0.000000
      speed:
         value:
            : 0.000000
         accuracy:
            : 0.000000
      reliability:
         reliabilityType: 0
      inclination:
         value:
            : 0.000000
         accuracy:
            : 0.000000
   identificationData:
      unitSymbol:
         : ""
      unitShortName:
         : ""
   operStatusData:
      footprint:
         : 0.000000
      strength:
         : 0
      statusCode:
         statusCodeType: 0
      alert:
         : FALSE
      remarks:
         : ""
   detailData:
      secPolicyName:
         : ""
      secClassification:
         : ""
      secCategory:
         : ""
trackType subscriber sleeping for 4 sec...
 
 
 
 
 

 

Offline
Last seen: 12 years 4 days ago
Joined: 10/30/2012
Posts: 2

Thanks Gerardo for the detail. Much appreciated. I will give the changes suggested and try with v1.3 and see how I get on. I am already generating valid v1.3 NFFI XML myself without attributes, i.e. the generated XML does not make use of any attributes but validates against the XSD successfully. Therefore if I can rtiddsgen some java code for both publisher and subscriber that is based on a modified XSD (minus the attributes) then this may suffice for now. Of course if in the future I wanted to make use of these then I may need to modify the rtiddsgen generated code (java) to include the use of attributes (if supported). Will let you know how I get on. 

Thanks again

Rob

Offline
Last seen: 11 years 6 months ago
Joined: 03/18/2013
Posts: 3

Hello Gerardo,

Thank you for this detailed instructive insight of XSD processing.
I reproduced all of these steps and errors: it is still the same.

You tutor to write the right xsd. But in my use case, i have to use a xsd definition from elsewhere (WXXM Weather Definition); rtiddsgen should be customisable for general xsd definition files.

Is there a promise about further development of rtiddsgen regarding XSD?

Best Reards
Roland

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 1 min ago
Joined: 06/02/2010
Posts: 602

Hello Ronald,

Yes we are well aware of the limitations of rtiddsgen with regards to processing exisiting XSDs.  We know it is causing pain out there and we definitely have the intent of improving this in the future so that we are able to process more general XSD.  I cannot give you a concrete date. The feature is an often requested one and we have it on the roadmap" but it has not been prioritized for the next release. 

In the meantime, even if we cannot accept a completely generic XSD, we are continually trying to identify the most common problems so we can prioritize those first. To this end it would be veru helpful to us if you could attach the XSD that is giving you trouble so we can analyze it and identify the things that cause problems, beyond the ones that we already noted in the context of the NFFI14.xsd

Thanks and Regards,

Gerardo