Schema CursorOnTargetCombined.xsd


schema location CursorOnTargetCombined.xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
CursorOnTarget 


schema location CoT Base-Event Schema (PUBLIC RELEASE).xsd
attributeFormDefault
elementFormDefault qualified
 
Elements 
detail 
event 
point 


schema location CoT Contact Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
contact 


schema location CoT Flow-Tags Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
_flow-tags_ 


schema location CoT Image Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
image 


schema location CoT Link Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
link 


schema location CoT Remarks Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
remarks 


schema location CoT Request Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
request 


schema location CoT Sensor Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
sensor 


schema location CoT Shape Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements  Simple types 
shape  nonNegativeDecimal 


schema location CoT Spatial Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
spatial 


schema location CoT Track Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
track 


schema location CoT Uid Schema (PUBLIC RELEASE).xsd
attributeFormDefault unqualified
elementFormDefault qualified
 
Elements 
uid 


element CursorOnTarget
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p1.png
properties
content complex
children contact detail event _flow-tags_ image link point remarks request sensor shape spatial track uid
annotation
documentation
Root element for a CoT stream
source <xs:element name="CursorOnTarget">
 
<xs:annotation>
   
<xs:documentation>Root element for a CoT stream</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:choice minOccurs="0" maxOccurs="unbounded">
     
<xs:element ref="contact"/>
     
<xs:element ref="detail"/>
     
<xs:element ref="event"/>
     
<xs:element ref="_flow-tags_"/>
     
<xs:element ref="image"/>
     
<xs:element ref="link"/>
     
<xs:element ref="point"/>
     
<xs:element ref="remarks"/>
     
<xs:element ref="request"/>
     
<xs:element ref="sensor"/>
     
<xs:element ref="shape"/>
     
<xs:element ref="spatial"/>
     
<xs:element ref="track"/>
     
<xs:element ref="uid"/>
   
</xs:choice>
 
</xs:complexType>
</xs:element>

element detail
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p2.png
properties
content complex
used by
elements CursorOnTarget event
attributes
Name  Type  Use  Default  Fixed  Annotation
annotation
documentation

    format = XML schema defined outside of this document

    Detail entities...

    The "detail" entity is intended to carry information that is
    specific to smaller communities of producers and consumers and
    require more intimate knowledge of the operating domain.  For
    example, mensurated "target" events may come from dramatically
    different sources and need to propagate dramatically different
    "detail" information.  A close-air-support mission will augment
    target details with initial point and callsign details to
    facilitate coordination of weapon delivery.  In contrast, a
    mission planning system may augment planned targets with target
    catalog information and weapon fuzing requirements.

    Because the "details" portion of the event are of interest only to
    a subset of subscribers, that entity may be mentioned by reference
    when the event is communicated.  This reduces the congestion when
    events are transmitted over bandwidth limited links and also
    prevents the retransmission of static data elements.
source <xs:element name="detail">
 
<xs:annotation>
   
<xs:documentation>
    format = XML schema defined outside of this document

    Detail entities...

    The "detail" entity is intended to carry information that is
    specific to smaller communities of producers and consumers and
    require more intimate knowledge of the operating domain.  For
    example, mensurated "target" events may come from dramatically
    different sources and need to propagate dramatically different
    "detail" information.  A close-air-support mission will augment
    target details with initial point and callsign details to
    facilitate coordination of weapon delivery.  In contrast, a
    mission planning system may augment planned targets with target
    catalog information and weapon fuzing requirements.

    Because the "details" portion of the event are of interest only to
    a subset of subscribers, that entity may be mentioned by reference
    when the event is communicated.  This reduces the congestion when
    events are transmitted over bandwidth limited links and also
    prevents the retransmission of static data elements.
</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:anyAttribute processContents="skip"/>
 
</xs:complexType>
</xs:element>

element event
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p3.png
properties
content complex
children point detail
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
version  derived by: xs:decimal  required      
type  derived by: xs:string  required      
documentation

   The "type" attribute is a composite of components delimited by the semi-colon
   character. The first component of this composite attribute is defined below.
   Future versions of this schema will define other components which we expect
   will aid in machine filtering. Despite the exclusion of definitions
   for additional components in this version of the schema, users of
   this schema should expect and design an optional trailing field
   delimited by the semi-colon character. This field can be ignored.

   component1;optional field
 
   The first component (component1) is a hierarchically organized hint about type.
   The intention is that this hierarchy be flexible and extensible and
   facilitate simple filtering, translation and display.  To
   facilitate  filtering, the hierarchy needs to present key
   fields in an easily parsed and logical order.  To facilitate
   this, this component is a composite of fields separated by the "-" punctuation
   character, so a valid type would be: x-x-X-X-x.  Using a
   punctuation for field separation allows arbitrary expansion of the
   type space, e.g., a-fzp-mlk-gm-...

   Field meanings are type specific.  That is, the third field of an
   "atom" type may represent air vs. ground while the same field for a
   "reservation" type may represent purpose.

   The "Atoms" portion of the type tree requires some additional
   explanation past the taxonomy defined below. The "Atoms" portion of
   the type tree contains CoT defined fields and part of the MIL-STD-2525
   type definition. To distinguish MIL-STD-2525 type strings from CoT defined
   fields, the MIL-STD-2525 types must be represented in all upper
   case. Differentiation of type namespace with upper/lower case
   facilitates extension of CoT types and MIL-STD-2525 types without
   name space confliction. An example:

   a-f-A-B-C-x

   The organization of CoT and MIL-STD-2525 types can be determined
   from the taxonomy below, but additional details are provided here.

   The "Atoms" portion of the "type" tree contains the "Battle
   Dimension" and  "Function ID" fields taken from MIL-STD-2525.
   "Battle Dimension" is a single character taken from
   MIL-STD-2525.

   The typical 2525 representation for "Function ID" is three groups of
   two characters separated by a space (e.g. "12 34 56"). The CoT
   schema maps this to a "-" delimited list of characters. (e.g. "1-2-3-4-5-6").
   The concatenation of the "Battle Dimension" and "Function ID" fields
   from the MIL-STD-2525 specification represented in the CoT schema
   will be as follows:

   battle dimension-func id char1-func id char2- ... -func id char6

   When an appropriate MIL-STD-2525 type exists, it should be used. If
   there is a MIL-STD-2525 representation which is close, but may be
   refined, a CoT extension to the 2525 type can be appended. For
   example...

   for example: a-h-X-X-X-X-X-i might represent

   hostile MIL-STD-2525 type X-X-X-X-X  of
   Israeli manufacture. Again, the CoT extension uses lower case.
   Conceptually, this extension defines further branching from the
   nearest MIL-STD-2525 tree point.

   If no appropriate 2525 representation exists, a type definition can
   be added to the CoT tree defined here. The resulting definition
   would be represented in all lower case. For example

   a-h-G-p-i

   might define atoms-hostile-Ground-photon cannon-infrared.

   The taxonomy currently looks like this: Note that the coding of the
   sub fields are determined entirely by the preceding fields!) The
   current type tree is defined here.

       +--- First position, this event describes
       |
       V

       a - Atoms - this event describes an actual "thing"

           +--- CoT affiliation of these atoms
           |
           V

           p - Pending
           u - Unknown
           a - Assumed friend
           f - Friend
           n - Neutral
           s - Suspect
           h - Hostile
           j - Joker
           k - Faker
           o - None specified
           x - Other

               +--- Battle dimension
               |    Taken from MIL-STD-2525 "Battle Dimension" (upper case)
               |
               V

               See MIL-STD-2525B specification for single charcter battle dimension

                   +--- Function (dimension specific!)
                   |   
                   |
                   V
                   ...
                   See MIL-STD-2525B specification for  function fields (must be upper case)   
                   ...

       +--- The event describes ...
       |
       V

       b - Bits - Events in the "Bit" group carry meta information
                  about raw data sources.  For example, range-doppler
                  radar returns or SAR imagery represent classes of
                  information that are "bits".  However, tracks
                  derived from such sources represent objects on the
                  battlespace and this have event type "A-..."

                  The intention with the "Bit" type is to facilitate
                  the identification of germane information products.
                  This hierarchy is not intended to replace more
                  detailed domain-specific meta information (such as
                  that contained in NITF image headers or the GMTI
                  data formats), rather it is intended to provide a
                  domain-neutral mechanism for rapid filtering of
                  information products.

           +--- Dimension
           |
           V

           i - Imagery
               e - Electro-optical
               i - Infra red
               s - SAR
               v - video
               ...
           r - Radar
               m - MTI data
               ...
           d - Sensor detection events
               s - Seismic
               d - Doppler
               a - Acoustic
               m - Motion (e.g., IR)
           m - Mapping
               p - Designated point (rally point, etc.)
                   i - initial points
                   r - rally points
                   ...

       r - Reservation/Restriction/References
                  Events in this category are generally "notices"
                  about specific areas.  These events are used for
                  deconfliction and conveyance of significant "area"
                  conditions.  Generally, the "point" entity will
                  describe a conical region that completely encloses
                  the affected area.  The details entity will provide
                  more specific bounds on precisely the region
                  affected.
           u - Unsafe (hostile capability)
           o - Occupied (e.g., SOF forces on ground)
           c - Contaminated (NBC event)
               c - chemical
                   x - agents, direction,
                   y
                   z
           f - Flight restrictions

       t - Tasking (requests/orders)
                  Events in this category are generalized requests for
                  service.  These may be used to request for data
                  collection, request mensuration of a specific
                  object, order an asset to take action against a
                  specific point.  Generally, the "details" entity
                  will identify the general or specific entity being
                  tasked.
           s - Surveillance
           r - Relocate
           e - Engage
           m - Mensurate

       c - Capability (applied to an area)
           s - Surveillance
           r - Rescue
           f - Fires
               d - Direct fires
               i - Indirect fires
           l - Logistics (supply)
               f - Fuel
               ...
           c - Communications
access  xs:string  optional      
documentation

The access field is intended to indicates who has access to this
        event. (e.g. unrestricted, nato, army, coalition...)
It is currently defined as a string, and is optional in V2.0.
Future version of the event schema will provide formal
definition of this field.
qos  derived by: xs:string  optional      
documentation

    format - digit-character-character as defined below

    The QoS attribute will determine the preferential treatment events
    receive as they proceed through the kill chain.  The field has
    several distinct but related components.

    A "priority" value indicates queuing and processing order for
    competing events.  At a processing bottleneck (e.g., bandwidth
    limited link) high priority events will be processed before lower
    priority events.  Priority determines queuing order at a
    bottleneck.

        9 - highest (most significant) priority
        0 - lowest (least significant) priority

    A "overtaking" value indicates how two events for the same uid are
    reconciled when they "catch up" to one another.  The more recent
    event (by timestamp) may supersede the older event (deleting the
    old event) when it catches it, or it may follow the old event so
    that event order is preserved, or it may be routed independently
    of previous events.

        r - replace - new event replaces (deletes) old event
        f - follow  - new event must follow previous events
        i - independent - new event processed independently of old events

    An "assurance" value indicates how much effort must be placed in
    delivering this particular event.  Events from sources that
    continually send updates (blue force tracks) or that are sent for
    information purposes only require a lower level of delivery
    effort.  Events that are singletons (sent only once) and are
    critical require guaranteed delivery.

        g - guaranteed delivery (message never dropped even if delivered late)
        d - deadline (message dropped only after "stale" time)
        c - congestion - message dropped when link congestion encountered

     Thus, a valid QoS field looks like:

        qos="1-r-c"

     Note that different events with the same UID may have differing
     QoS values.  This enables a graceful degradation in the presence
     of congestion.  For example, a blue force tracker may output a
     sequence of events with like
         ... qos="1-r-c" ...  frequent, low priority updates
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="5-r-d" ...  occasional "push" priority update
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="9-r-g" ...  "Mayday" position report

opex  xs:string  optional      
documentation

  The opex field is intended to indicate that the event is part of a
  live operation, an exercise, or a simulation.  For backward compatibility, absence
  of the opex indicates "no statement", which will be interpreted in
  an installation specific manner.
 
  opex="o-&lt;name&gt;" or "e-&lt;nickname&gt;"  or "s-&lt;nickname&gt;",
  where "-&lt;name&gt;" is optional.  That is, it is permissible to
  specify only "o", "e", or "s" for the opex value.

  o = operations
  e = exercise
  s = simulation
uid  xs:string  required      
documentation

The "uid" attribute is a globally unique name for this specific piece of information.
Several "events" may be associated with one UID, but in that case, the latest (ordered by timestamp),
overwrites all previous events for that UID.
time  xs:dateTime  required      
documentation

The CoT XML schema includes three time values:
time, start, and stale.  "time" is a time stamp placed on the event
when generated. start and stale define an interval in time for which
the event is valid. Example: For the scenario where we have intel
reports about a meeting of terrorist operatives later in the day: An
event might be generated at noon (time) to describe a ground based
target which is valid from 1300 (start) until 1330 (stale).  All time
fields are required. In version 1.1 of the CoT schema, the time and stale
attributes together defined and interval of time for which the event was
valid. In V2.0, time indicates the "birth" of an event and the start and stale pair
define the validity interval.

The "time" attribute is a time stamp indicating when an event was generated.
The format of time, start, and stale are in standard date format (ISO 8601):
CCYY-MM-DDThh:mm:ss.ssZ (e.g., 2002-10-05T17:01:14.00Z), where the presence of
fractional seconds (including the delimeter) is optional.  Also, there is no constraint
on the number of digits to use for fractional seconds.  The following are all valid:
2002-10-05T18:00:23Z,  2002-10-05T18:00:23.12Z, 2002-10-05T18:00:23.123456Z
start  xs:dateTime  required      
documentation

  format - DTG

The "start" attribute defines the starting time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and stale.
stale  xs:dateTime  required      
documentation

The "stale" attribute defines the ending time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and start.
how  derived by: xs:string  required      
documentation

format = character-character

    The "how" attribute gives a hint about how the coordinates were
    generated.  It is used specifically to relay a hint about the
    types of errors that may be expected in the data and to weight the
    data in systems that fuse multiple inputs.  For example,
    coordinates transcribed by humans may have digit transposition,
    missing or repeated digits, estimated error bounds, etc.  As such,
    they may require special attention as they propagate through the
    kill chain (e.g., they may require an additional review).
    Similarly, machine generated coordinates derived solely from
    magnetic sources may be subject to known anomalies in certain
    geographical areas, etc.

        h - human entered or modified (someone typed the coordinates)
            e - estimated (a swag by the user)
            c - calculated (user probably calculated value by hand)
            t - transcribed (from voice, paper, ...)
            p - cut and paste from another window
        m - machine generated
            i - mensurated (from imagery)
            g - derived from GPS receiver
            m - magnetic    - derived from magnetic sources
            s - simulated   - out of a simulation
            f - fused       - corroborated from multiple sources
            c - configured  - out of a configuration file
            p - predicted   - prediction of future (e.g., a from a tracker)
            r - relayed     - imported from another system (gateway)

  As with other compound fields, the elements of the how field
  will be delimited by the field separator character "-".  E.g,
  A coordinate mensurated from imagery would have a how field of "m-i".
annotation
documentation
Event Definition
source <xs:element name="event">
 
<xs:annotation>
   
<xs:documentation>Event Definition</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:all>
     
<xs:element ref="point"/>
     
<xs:element ref="detail" minOccurs="0"/>
   
</xs:all>
   
<xs:attribute name="version" use="required">
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="2"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="type" use="required">
     
<xs:annotation>
       
<xs:documentation>
   The "type" attribute is a composite of components delimited by the semi-colon
   character. The first component of this composite attribute is defined below.
   Future versions of this schema will define other components which we expect
   will aid in machine filtering. Despite the exclusion of definitions
   for additional components in this version of the schema, users of
   this schema should expect and design an optional trailing field
   delimited by the semi-colon character. This field can be ignored.

   component1;optional field
 
   The first component (component1) is a hierarchically organized hint about type.
   The intention is that this hierarchy be flexible and extensible and
   facilitate simple filtering, translation and display.  To
   facilitate  filtering, the hierarchy needs to present key
   fields in an easily parsed and logical order.  To facilitate
   this, this component is a composite of fields separated by the "-" punctuation
   character, so a valid type would be: x-x-X-X-x.  Using a
   punctuation for field separation allows arbitrary expansion of the
   type space, e.g., a-fzp-mlk-gm-...

   Field meanings are type specific.  That is, the third field of an
   "atom" type may represent air vs. ground while the same field for a
   "reservation" type may represent purpose.

   The "Atoms" portion of the type tree requires some additional
   explanation past the taxonomy defined below. The "Atoms" portion of
   the type tree contains CoT defined fields and part of the MIL-STD-2525
   type definition. To distinguish MIL-STD-2525 type strings from CoT defined
   fields, the MIL-STD-2525 types must be represented in all upper
   case. Differentiation of type namespace with upper/lower case
   facilitates extension of CoT types and MIL-STD-2525 types without
   name space confliction. An example:

   a-f-A-B-C-x

   The organization of CoT and MIL-STD-2525 types can be determined
   from the taxonomy below, but additional details are provided here.

   The "Atoms" portion of the "type" tree contains the "Battle
   Dimension" and  "Function ID" fields taken from MIL-STD-2525.
   "Battle Dimension" is a single character taken from
   MIL-STD-2525.

   The typical 2525 representation for "Function ID" is three groups of
   two characters separated by a space (e.g. "12 34 56"). The CoT
   schema maps this to a "-" delimited list of characters. (e.g. "1-2-3-4-5-6").
   The concatenation of the "Battle Dimension" and "Function ID" fields
   from the MIL-STD-2525 specification represented in the CoT schema
   will be as follows:

   battle dimension-func id char1-func id char2- ... -func id char6

   When an appropriate MIL-STD-2525 type exists, it should be used. If
   there is a MIL-STD-2525 representation which is close, but may be
   refined, a CoT extension to the 2525 type can be appended. For
   example...

   for example: a-h-X-X-X-X-X-i might represent

   hostile MIL-STD-2525 type X-X-X-X-X  of
   Israeli manufacture. Again, the CoT extension uses lower case.
   Conceptually, this extension defines further branching from the
   nearest MIL-STD-2525 tree point.

   If no appropriate 2525 representation exists, a type definition can
   be added to the CoT tree defined here. The resulting definition
   would be represented in all lower case. For example

   a-h-G-p-i

   might define atoms-hostile-Ground-photon cannon-infrared.

   The taxonomy currently looks like this: Note that the coding of the
   sub fields are determined entirely by the preceding fields!) The
   current type tree is defined here.

       +--- First position, this event describes
       |
       V

       a - Atoms - this event describes an actual "thing"

           +--- CoT affiliation of these atoms
           |
           V

           p - Pending
           u - Unknown
           a - Assumed friend
           f - Friend
           n - Neutral
           s - Suspect
           h - Hostile
           j - Joker
           k - Faker
           o - None specified
           x - Other

               +--- Battle dimension
               |    Taken from MIL-STD-2525 "Battle Dimension" (upper case)
               |
               V

               See MIL-STD-2525B specification for single charcter battle dimension

                   +--- Function (dimension specific!)
                   |   
                   |
                   V
                   ...
                   See MIL-STD-2525B specification for  function fields (must be upper case)   
                   ...

       +--- The event describes ...
       |
       V

       b - Bits - Events in the "Bit" group carry meta information
                  about raw data sources.  For example, range-doppler
                  radar returns or SAR imagery represent classes of
                  information that are "bits".  However, tracks
                  derived from such sources represent objects on the
                  battlespace and this have event type "A-..."

                  The intention with the "Bit" type is to facilitate
                  the identification of germane information products.
                  This hierarchy is not intended to replace more
                  detailed domain-specific meta information (such as
                  that contained in NITF image headers or the GMTI
                  data formats), rather it is intended to provide a
                  domain-neutral mechanism for rapid filtering of
                  information products.

           +--- Dimension
           |
           V

           i - Imagery
               e - Electro-optical
               i - Infra red
               s - SAR
               v - video
               ...
           r - Radar
               m - MTI data
               ...
           d - Sensor detection events
               s - Seismic
               d - Doppler
               a - Acoustic
               m - Motion (e.g., IR)
           m - Mapping
               p - Designated point (rally point, etc.)
                   i - initial points
                   r - rally points
                   ...

       r - Reservation/Restriction/References
                  Events in this category are generally "notices"
                  about specific areas.  These events are used for
                  deconfliction and conveyance of significant "area"
                  conditions.  Generally, the "point" entity will
                  describe a conical region that completely encloses
                  the affected area.  The details entity will provide
                  more specific bounds on precisely the region
                  affected.
           u - Unsafe (hostile capability)
           o - Occupied (e.g., SOF forces on ground)
           c - Contaminated (NBC event)
               c - chemical
                   x - agents, direction,
                   y
                   z
           f - Flight restrictions

       t - Tasking (requests/orders)
                  Events in this category are generalized requests for
                  service.  These may be used to request for data
                  collection, request mensuration of a specific
                  object, order an asset to take action against a
                  specific point.  Generally, the "details" entity
                  will identify the general or specific entity being
                  tasked.
           s - Surveillance
           r - Relocate
           e - Engage
           m - Mensurate

       c - Capability (applied to an area)
           s - Surveillance
           r - Rescue
           f - Fires
               d - Direct fires
               i - Indirect fires
           l - Logistics (supply)
               f - Fuel
               ...
           c - Communications
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:string">
         
<xs:pattern value="\w+(-\w+)*(;[^;]*)?"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="access" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>
The access field is intended to indicates who has access to this
        event. (e.g. unrestricted, nato, army, coalition...)
It is currently defined as a string, and is optional in V2.0.
Future version of the event schema will provide formal
definition of this field.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="qos" use="optional">
     
<xs:annotation>
       
<xs:documentation>
    format - digit-character-character as defined below

    The QoS attribute will determine the preferential treatment events
    receive as they proceed through the kill chain.  The field has
    several distinct but related components.

    A "priority" value indicates queuing and processing order for
    competing events.  At a processing bottleneck (e.g., bandwidth
    limited link) high priority events will be processed before lower
    priority events.  Priority determines queuing order at a
    bottleneck.

        9 - highest (most significant) priority
        0 - lowest (least significant) priority

    A "overtaking" value indicates how two events for the same uid are
    reconciled when they "catch up" to one another.  The more recent
    event (by timestamp) may supersede the older event (deleting the
    old event) when it catches it, or it may follow the old event so
    that event order is preserved, or it may be routed independently
    of previous events.

        r - replace - new event replaces (deletes) old event
        f - follow  - new event must follow previous events
        i - independent - new event processed independently of old events

    An "assurance" value indicates how much effort must be placed in
    delivering this particular event.  Events from sources that
    continually send updates (blue force tracks) or that are sent for
    information purposes only require a lower level of delivery
    effort.  Events that are singletons (sent only once) and are
    critical require guaranteed delivery.

        g - guaranteed delivery (message never dropped even if delivered late)
        d - deadline (message dropped only after "stale" time)
        c - congestion - message dropped when link congestion encountered

     Thus, a valid QoS field looks like:

        qos="1-r-c"

     Note that different events with the same UID may have differing
     QoS values.  This enables a graceful degradation in the presence
     of congestion.  For example, a blue force tracker may output a
     sequence of events with like
         ... qos="1-r-c" ...  frequent, low priority updates
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="5-r-d" ...  occasional "push" priority update
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="9-r-g" ...  "Mayday" position report

</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:string">
         
<xs:pattern value="\d-\w-\w"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="opex" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>
  The opex field is intended to indicate that the event is part of a
  live operation, an exercise, or a simulation.  For backward compatibility, absence
  of the opex indicates "no statement", which will be interpreted in
  an installation specific manner.
 
  opex="o-&lt;name&gt;" or "e-&lt;nickname&gt;"  or "s-&lt;nickname&gt;",
  where "-&lt;name&gt;" is optional.  That is, it is permissible to
  specify only "o", "e", or "s" for the opex value.

  o = operations
  e = exercise
  s = simulation
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="uid" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>
The "uid" attribute is a globally unique name for this specific piece of information.
Several "events" may be associated with one UID, but in that case, the latest (ordered by timestamp),
overwrites all previous events for that UID.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="time" type="xs:dateTime" use="required">
     
<xs:annotation>
       
<xs:documentation>
The CoT XML schema includes three time values:
time, start, and stale.  "time" is a time stamp placed on the event
when generated. start and stale define an interval in time for which
the event is valid. Example: For the scenario where we have intel
reports about a meeting of terrorist operatives later in the day: An
event might be generated at noon (time) to describe a ground based
target which is valid from 1300 (start) until 1330 (stale).  All time
fields are required. In version 1.1 of the CoT schema, the time and stale
attributes together defined and interval of time for which the event was
valid. In V2.0, time indicates the "birth" of an event and the start and stale pair
define the validity interval.

The "time" attribute is a time stamp indicating when an event was generated.
The format of time, start, and stale are in standard date format (ISO 8601):
CCYY-MM-DDThh:mm:ss.ssZ (e.g., 2002-10-05T17:01:14.00Z), where the presence of
fractional seconds (including the delimeter) is optional.  Also, there is no constraint
on the number of digits to use for fractional seconds.  The following are all valid:
2002-10-05T18:00:23Z,  2002-10-05T18:00:23.12Z, 2002-10-05T18:00:23.123456Z
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="start" type="xs:dateTime" use="required">
     
<xs:annotation>
       
<xs:documentation>
  format - DTG

The "start" attribute defines the starting time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and stale.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="stale" type="xs:dateTime" use="required">
     
<xs:annotation>
       
<xs:documentation>
The "stale" attribute defines the ending time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and start.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="how" use="required">
     
<xs:annotation>
       
<xs:documentation>
format = character-character

    The "how" attribute gives a hint about how the coordinates were
    generated.  It is used specifically to relay a hint about the
    types of errors that may be expected in the data and to weight the
    data in systems that fuse multiple inputs.  For example,
    coordinates transcribed by humans may have digit transposition,
    missing or repeated digits, estimated error bounds, etc.  As such,
    they may require special attention as they propagate through the
    kill chain (e.g., they may require an additional review).
    Similarly, machine generated coordinates derived solely from
    magnetic sources may be subject to known anomalies in certain
    geographical areas, etc.

        h - human entered or modified (someone typed the coordinates)
            e - estimated (a swag by the user)
            c - calculated (user probably calculated value by hand)
            t - transcribed (from voice, paper, ...)
            p - cut and paste from another window
        m - machine generated
            i - mensurated (from imagery)
            g - derived from GPS receiver
            m - magnetic    - derived from magnetic sources
            s - simulated   - out of a simulation
            f - fused       - corroborated from multiple sources
            c - configured  - out of a configuration file
            p - predicted   - prediction of future (e.g., a from a tracker)
            r - relayed     - imported from another system (gateway)

  As with other compound fields, the elements of the how field
  will be delimited by the field separator character "-".  E.g,
  A coordinate mensurated from imagery would have a how field of "m-i".
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:string">
         
<xs:pattern value="\w(-\w+)*"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute event/@version
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive 2
source <xs:attribute name="version" use="required">
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="2"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute event/@type
type restriction of xs:string
properties
use required
facets
Kind Value Annotation
pattern \w+(-\w+)*(;[^;]*)?
annotation
documentation

   The "type" attribute is a composite of components delimited by the semi-colon
   character. The first component of this composite attribute is defined below.
   Future versions of this schema will define other components which we expect
   will aid in machine filtering. Despite the exclusion of definitions
   for additional components in this version of the schema, users of
   this schema should expect and design an optional trailing field
   delimited by the semi-colon character. This field can be ignored.

   component1;optional field
 
   The first component (component1) is a hierarchically organized hint about type.
   The intention is that this hierarchy be flexible and extensible and
   facilitate simple filtering, translation and display.  To
   facilitate  filtering, the hierarchy needs to present key
   fields in an easily parsed and logical order.  To facilitate
   this, this component is a composite of fields separated by the "-" punctuation
   character, so a valid type would be: x-x-X-X-x.  Using a
   punctuation for field separation allows arbitrary expansion of the
   type space, e.g., a-fzp-mlk-gm-...

   Field meanings are type specific.  That is, the third field of an
   "atom" type may represent air vs. ground while the same field for a
   "reservation" type may represent purpose.

   The "Atoms" portion of the type tree requires some additional
   explanation past the taxonomy defined below. The "Atoms" portion of
   the type tree contains CoT defined fields and part of the MIL-STD-2525
   type definition. To distinguish MIL-STD-2525 type strings from CoT defined
   fields, the MIL-STD-2525 types must be represented in all upper
   case. Differentiation of type namespace with upper/lower case
   facilitates extension of CoT types and MIL-STD-2525 types without
   name space confliction. An example:

   a-f-A-B-C-x

   The organization of CoT and MIL-STD-2525 types can be determined
   from the taxonomy below, but additional details are provided here.

   The "Atoms" portion of the "type" tree contains the "Battle
   Dimension" and  "Function ID" fields taken from MIL-STD-2525.
   "Battle Dimension" is a single character taken from
   MIL-STD-2525.

   The typical 2525 representation for "Function ID" is three groups of
   two characters separated by a space (e.g. "12 34 56"). The CoT
   schema maps this to a "-" delimited list of characters. (e.g. "1-2-3-4-5-6").
   The concatenation of the "Battle Dimension" and "Function ID" fields
   from the MIL-STD-2525 specification represented in the CoT schema
   will be as follows:

   battle dimension-func id char1-func id char2- ... -func id char6

   When an appropriate MIL-STD-2525 type exists, it should be used. If
   there is a MIL-STD-2525 representation which is close, but may be
   refined, a CoT extension to the 2525 type can be appended. For
   example...

   for example: a-h-X-X-X-X-X-i might represent

   hostile MIL-STD-2525 type X-X-X-X-X  of
   Israeli manufacture. Again, the CoT extension uses lower case.
   Conceptually, this extension defines further branching from the
   nearest MIL-STD-2525 tree point.

   If no appropriate 2525 representation exists, a type definition can
   be added to the CoT tree defined here. The resulting definition
   would be represented in all lower case. For example

   a-h-G-p-i

   might define atoms-hostile-Ground-photon cannon-infrared.

   The taxonomy currently looks like this: Note that the coding of the
   sub fields are determined entirely by the preceding fields!) The
   current type tree is defined here.

       +--- First position, this event describes
       |
       V

       a - Atoms - this event describes an actual "thing"

           +--- CoT affiliation of these atoms
           |
           V

           p - Pending
           u - Unknown
           a - Assumed friend
           f - Friend
           n - Neutral
           s - Suspect
           h - Hostile
           j - Joker
           k - Faker
           o - None specified
           x - Other

               +--- Battle dimension
               |    Taken from MIL-STD-2525 "Battle Dimension" (upper case)
               |
               V

               See MIL-STD-2525B specification for single charcter battle dimension

                   +--- Function (dimension specific!)
                   |   
                   |
                   V
                   ...
                   See MIL-STD-2525B specification for  function fields (must be upper case)   
                   ...

       +--- The event describes ...
       |
       V

       b - Bits - Events in the "Bit" group carry meta information
                  about raw data sources.  For example, range-doppler
                  radar returns or SAR imagery represent classes of
                  information that are "bits".  However, tracks
                  derived from such sources represent objects on the
                  battlespace and this have event type "A-..."

                  The intention with the "Bit" type is to facilitate
                  the identification of germane information products.
                  This hierarchy is not intended to replace more
                  detailed domain-specific meta information (such as
                  that contained in NITF image headers or the GMTI
                  data formats), rather it is intended to provide a
                  domain-neutral mechanism for rapid filtering of
                  information products.

           +--- Dimension
           |
           V

           i - Imagery
               e - Electro-optical
               i - Infra red
               s - SAR
               v - video
               ...
           r - Radar
               m - MTI data
               ...
           d - Sensor detection events
               s - Seismic
               d - Doppler
               a - Acoustic
               m - Motion (e.g., IR)
           m - Mapping
               p - Designated point (rally point, etc.)
                   i - initial points
                   r - rally points
                   ...

       r - Reservation/Restriction/References
                  Events in this category are generally "notices"
                  about specific areas.  These events are used for
                  deconfliction and conveyance of significant "area"
                  conditions.  Generally, the "point" entity will
                  describe a conical region that completely encloses
                  the affected area.  The details entity will provide
                  more specific bounds on precisely the region
                  affected.
           u - Unsafe (hostile capability)
           o - Occupied (e.g., SOF forces on ground)
           c - Contaminated (NBC event)
               c - chemical
                   x - agents, direction,
                   y
                   z
           f - Flight restrictions

       t - Tasking (requests/orders)
                  Events in this category are generalized requests for
                  service.  These may be used to request for data
                  collection, request mensuration of a specific
                  object, order an asset to take action against a
                  specific point.  Generally, the "details" entity
                  will identify the general or specific entity being
                  tasked.
           s - Surveillance
           r - Relocate
           e - Engage
           m - Mensurate

       c - Capability (applied to an area)
           s - Surveillance
           r - Rescue
           f - Fires
               d - Direct fires
               i - Indirect fires
           l - Logistics (supply)
               f - Fuel
               ...
           c - Communications
source <xs:attribute name="type" use="required">
 
<xs:annotation>
   
<xs:documentation>
   The "type" attribute is a composite of components delimited by the semi-colon
   character. The first component of this composite attribute is defined below.
   Future versions of this schema will define other components which we expect
   will aid in machine filtering. Despite the exclusion of definitions
   for additional components in this version of the schema, users of
   this schema should expect and design an optional trailing field
   delimited by the semi-colon character. This field can be ignored.

   component1;optional field
 
   The first component (component1) is a hierarchically organized hint about type.
   The intention is that this hierarchy be flexible and extensible and
   facilitate simple filtering, translation and display.  To
   facilitate  filtering, the hierarchy needs to present key
   fields in an easily parsed and logical order.  To facilitate
   this, this component is a composite of fields separated by the "-" punctuation
   character, so a valid type would be: x-x-X-X-x.  Using a
   punctuation for field separation allows arbitrary expansion of the
   type space, e.g., a-fzp-mlk-gm-...

   Field meanings are type specific.  That is, the third field of an
   "atom" type may represent air vs. ground while the same field for a
   "reservation" type may represent purpose.

   The "Atoms" portion of the type tree requires some additional
   explanation past the taxonomy defined below. The "Atoms" portion of
   the type tree contains CoT defined fields and part of the MIL-STD-2525
   type definition. To distinguish MIL-STD-2525 type strings from CoT defined
   fields, the MIL-STD-2525 types must be represented in all upper
   case. Differentiation of type namespace with upper/lower case
   facilitates extension of CoT types and MIL-STD-2525 types without
   name space confliction. An example:

   a-f-A-B-C-x

   The organization of CoT and MIL-STD-2525 types can be determined
   from the taxonomy below, but additional details are provided here.

   The "Atoms" portion of the "type" tree contains the "Battle
   Dimension" and  "Function ID" fields taken from MIL-STD-2525.
   "Battle Dimension" is a single character taken from
   MIL-STD-2525.

   The typical 2525 representation for "Function ID" is three groups of
   two characters separated by a space (e.g. "12 34 56"). The CoT
   schema maps this to a "-" delimited list of characters. (e.g. "1-2-3-4-5-6").
   The concatenation of the "Battle Dimension" and "Function ID" fields
   from the MIL-STD-2525 specification represented in the CoT schema
   will be as follows:

   battle dimension-func id char1-func id char2- ... -func id char6

   When an appropriate MIL-STD-2525 type exists, it should be used. If
   there is a MIL-STD-2525 representation which is close, but may be
   refined, a CoT extension to the 2525 type can be appended. For
   example...

   for example: a-h-X-X-X-X-X-i might represent

   hostile MIL-STD-2525 type X-X-X-X-X  of
   Israeli manufacture. Again, the CoT extension uses lower case.
   Conceptually, this extension defines further branching from the
   nearest MIL-STD-2525 tree point.

   If no appropriate 2525 representation exists, a type definition can
   be added to the CoT tree defined here. The resulting definition
   would be represented in all lower case. For example

   a-h-G-p-i

   might define atoms-hostile-Ground-photon cannon-infrared.

   The taxonomy currently looks like this: Note that the coding of the
   sub fields are determined entirely by the preceding fields!) The
   current type tree is defined here.

       +--- First position, this event describes
       |
       V

       a - Atoms - this event describes an actual "thing"

           +--- CoT affiliation of these atoms
           |
           V

           p - Pending
           u - Unknown
           a - Assumed friend
           f - Friend
           n - Neutral
           s - Suspect
           h - Hostile
           j - Joker
           k - Faker
           o - None specified
           x - Other

               +--- Battle dimension
               |    Taken from MIL-STD-2525 "Battle Dimension" (upper case)
               |
               V

               See MIL-STD-2525B specification for single charcter battle dimension

                   +--- Function (dimension specific!)
                   |   
                   |
                   V
                   ...
                   See MIL-STD-2525B specification for  function fields (must be upper case)   
                   ...

       +--- The event describes ...
       |
       V

       b - Bits - Events in the "Bit" group carry meta information
                  about raw data sources.  For example, range-doppler
                  radar returns or SAR imagery represent classes of
                  information that are "bits".  However, tracks
                  derived from such sources represent objects on the
                  battlespace and this have event type "A-..."

                  The intention with the "Bit" type is to facilitate
                  the identification of germane information products.
                  This hierarchy is not intended to replace more
                  detailed domain-specific meta information (such as
                  that contained in NITF image headers or the GMTI
                  data formats), rather it is intended to provide a
                  domain-neutral mechanism for rapid filtering of
                  information products.

           +--- Dimension
           |
           V

           i - Imagery
               e - Electro-optical
               i - Infra red
               s - SAR
               v - video
               ...
           r - Radar
               m - MTI data
               ...
           d - Sensor detection events
               s - Seismic
               d - Doppler
               a - Acoustic
               m - Motion (e.g., IR)
           m - Mapping
               p - Designated point (rally point, etc.)
                   i - initial points
                   r - rally points
                   ...

       r - Reservation/Restriction/References
                  Events in this category are generally "notices"
                  about specific areas.  These events are used for
                  deconfliction and conveyance of significant "area"
                  conditions.  Generally, the "point" entity will
                  describe a conical region that completely encloses
                  the affected area.  The details entity will provide
                  more specific bounds on precisely the region
                  affected.
           u - Unsafe (hostile capability)
           o - Occupied (e.g., SOF forces on ground)
           c - Contaminated (NBC event)
               c - chemical
                   x - agents, direction,
                   y
                   z
           f - Flight restrictions

       t - Tasking (requests/orders)
                  Events in this category are generalized requests for
                  service.  These may be used to request for data
                  collection, request mensuration of a specific
                  object, order an asset to take action against a
                  specific point.  Generally, the "details" entity
                  will identify the general or specific entity being
                  tasked.
           s - Surveillance
           r - Relocate
           e - Engage
           m - Mensurate

       c - Capability (applied to an area)
           s - Surveillance
           r - Rescue
           f - Fires
               d - Direct fires
               i - Indirect fires
           l - Logistics (supply)
               f - Fuel
               ...
           c - Communications
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:string">
     
<xs:pattern value="\w+(-\w+)*(;[^;]*)?"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute event/@access
type xs:string
properties
use optional
annotation
documentation

The access field is intended to indicates who has access to this
        event. (e.g. unrestricted, nato, army, coalition...)
It is currently defined as a string, and is optional in V2.0.
Future version of the event schema will provide formal
definition of this field.
source <xs:attribute name="access" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>
The access field is intended to indicates who has access to this
        event. (e.g. unrestricted, nato, army, coalition...)
It is currently defined as a string, and is optional in V2.0.
Future version of the event schema will provide formal
definition of this field.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@qos
type restriction of xs:string
properties
use optional
facets
Kind Value Annotation
pattern \d-\w-\w
annotation
documentation

    format - digit-character-character as defined below

    The QoS attribute will determine the preferential treatment events
    receive as they proceed through the kill chain.  The field has
    several distinct but related components.

    A "priority" value indicates queuing and processing order for
    competing events.  At a processing bottleneck (e.g., bandwidth
    limited link) high priority events will be processed before lower
    priority events.  Priority determines queuing order at a
    bottleneck.

        9 - highest (most significant) priority
        0 - lowest (least significant) priority

    A "overtaking" value indicates how two events for the same uid are
    reconciled when they "catch up" to one another.  The more recent
    event (by timestamp) may supersede the older event (deleting the
    old event) when it catches it, or it may follow the old event so
    that event order is preserved, or it may be routed independently
    of previous events.

        r - replace - new event replaces (deletes) old event
        f - follow  - new event must follow previous events
        i - independent - new event processed independently of old events

    An "assurance" value indicates how much effort must be placed in
    delivering this particular event.  Events from sources that
    continually send updates (blue force tracks) or that are sent for
    information purposes only require a lower level of delivery
    effort.  Events that are singletons (sent only once) and are
    critical require guaranteed delivery.

        g - guaranteed delivery (message never dropped even if delivered late)
        d - deadline (message dropped only after "stale" time)
        c - congestion - message dropped when link congestion encountered

     Thus, a valid QoS field looks like:

        qos="1-r-c"

     Note that different events with the same UID may have differing
     QoS values.  This enables a graceful degradation in the presence
     of congestion.  For example, a blue force tracker may output a
     sequence of events with like
         ... qos="1-r-c" ...  frequent, low priority updates
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="5-r-d" ...  occasional "push" priority update
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="9-r-g" ...  "Mayday" position report

source <xs:attribute name="qos" use="optional">
 
<xs:annotation>
   
<xs:documentation>
    format - digit-character-character as defined below

    The QoS attribute will determine the preferential treatment events
    receive as they proceed through the kill chain.  The field has
    several distinct but related components.

    A "priority" value indicates queuing and processing order for
    competing events.  At a processing bottleneck (e.g., bandwidth
    limited link) high priority events will be processed before lower
    priority events.  Priority determines queuing order at a
    bottleneck.

        9 - highest (most significant) priority
        0 - lowest (least significant) priority

    A "overtaking" value indicates how two events for the same uid are
    reconciled when they "catch up" to one another.  The more recent
    event (by timestamp) may supersede the older event (deleting the
    old event) when it catches it, or it may follow the old event so
    that event order is preserved, or it may be routed independently
    of previous events.

        r - replace - new event replaces (deletes) old event
        f - follow  - new event must follow previous events
        i - independent - new event processed independently of old events

    An "assurance" value indicates how much effort must be placed in
    delivering this particular event.  Events from sources that
    continually send updates (blue force tracks) or that are sent for
    information purposes only require a lower level of delivery
    effort.  Events that are singletons (sent only once) and are
    critical require guaranteed delivery.

        g - guaranteed delivery (message never dropped even if delivered late)
        d - deadline (message dropped only after "stale" time)
        c - congestion - message dropped when link congestion encountered

     Thus, a valid QoS field looks like:

        qos="1-r-c"

     Note that different events with the same UID may have differing
     QoS values.  This enables a graceful degradation in the presence
     of congestion.  For example, a blue force tracker may output a
     sequence of events with like
         ... qos="1-r-c" ...  frequent, low priority updates
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="5-r-d" ...  occasional "push" priority update
         ... qos="1-r-c" ...
         ... qos="1-r-c" ...
         ... qos="9-r-g" ...  "Mayday" position report

</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:string">
     
<xs:pattern value="\d-\w-\w"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute event/@opex
type xs:string
properties
use optional
annotation
documentation

  The opex field is intended to indicate that the event is part of a
  live operation, an exercise, or a simulation.  For backward compatibility, absence
  of the opex indicates "no statement", which will be interpreted in
  an installation specific manner.
 
  opex="o-&lt;name&gt;" or "e-&lt;nickname&gt;"  or "s-&lt;nickname&gt;",
  where "-&lt;name&gt;" is optional.  That is, it is permissible to
  specify only "o", "e", or "s" for the opex value.

  o = operations
  e = exercise
  s = simulation
source <xs:attribute name="opex" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>
  The opex field is intended to indicate that the event is part of a
  live operation, an exercise, or a simulation.  For backward compatibility, absence
  of the opex indicates "no statement", which will be interpreted in
  an installation specific manner.
 
  opex="o-&lt;name&gt;" or "e-&lt;nickname&gt;"  or "s-&lt;nickname&gt;",
  where "-&lt;name&gt;" is optional.  That is, it is permissible to
  specify only "o", "e", or "s" for the opex value.

  o = operations
  e = exercise
  s = simulation
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@uid
type xs:string
properties
use required
annotation
documentation

The "uid" attribute is a globally unique name for this specific piece of information.
Several "events" may be associated with one UID, but in that case, the latest (ordered by timestamp),
overwrites all previous events for that UID.
source <xs:attribute name="uid" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>
The "uid" attribute is a globally unique name for this specific piece of information.
Several "events" may be associated with one UID, but in that case, the latest (ordered by timestamp),
overwrites all previous events for that UID.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@time
type xs:dateTime
properties
use required
annotation
documentation

The CoT XML schema includes three time values:
time, start, and stale.  "time" is a time stamp placed on the event
when generated. start and stale define an interval in time for which
the event is valid. Example: For the scenario where we have intel
reports about a meeting of terrorist operatives later in the day: An
event might be generated at noon (time) to describe a ground based
target which is valid from 1300 (start) until 1330 (stale).  All time
fields are required. In version 1.1 of the CoT schema, the time and stale
attributes together defined and interval of time for which the event was
valid. In V2.0, time indicates the "birth" of an event and the start and stale pair
define the validity interval.

The "time" attribute is a time stamp indicating when an event was generated.
The format of time, start, and stale are in standard date format (ISO 8601):
CCYY-MM-DDThh:mm:ss.ssZ (e.g., 2002-10-05T17:01:14.00Z), where the presence of
fractional seconds (including the delimeter) is optional.  Also, there is no constraint
on the number of digits to use for fractional seconds.  The following are all valid:
2002-10-05T18:00:23Z,  2002-10-05T18:00:23.12Z, 2002-10-05T18:00:23.123456Z
source <xs:attribute name="time" type="xs:dateTime" use="required">
 
<xs:annotation>
   
<xs:documentation>
The CoT XML schema includes three time values:
time, start, and stale.  "time" is a time stamp placed on the event
when generated. start and stale define an interval in time for which
the event is valid. Example: For the scenario where we have intel
reports about a meeting of terrorist operatives later in the day: An
event might be generated at noon (time) to describe a ground based
target which is valid from 1300 (start) until 1330 (stale).  All time
fields are required. In version 1.1 of the CoT schema, the time and stale
attributes together defined and interval of time for which the event was
valid. In V2.0, time indicates the "birth" of an event and the start and stale pair
define the validity interval.

The "time" attribute is a time stamp indicating when an event was generated.
The format of time, start, and stale are in standard date format (ISO 8601):
CCYY-MM-DDThh:mm:ss.ssZ (e.g., 2002-10-05T17:01:14.00Z), where the presence of
fractional seconds (including the delimeter) is optional.  Also, there is no constraint
on the number of digits to use for fractional seconds.  The following are all valid:
2002-10-05T18:00:23Z,  2002-10-05T18:00:23.12Z, 2002-10-05T18:00:23.123456Z
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@start
type xs:dateTime
properties
use required
annotation
documentation

  format - DTG

The "start" attribute defines the starting time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and stale.
source <xs:attribute name="start" type="xs:dateTime" use="required">
 
<xs:annotation>
   
<xs:documentation>
  format - DTG

The "start" attribute defines the starting time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and stale.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@stale
type xs:dateTime
properties
use required
annotation
documentation

The "stale" attribute defines the ending time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and start.
source <xs:attribute name="stale" type="xs:dateTime" use="required">
 
<xs:annotation>
   
<xs:documentation>
The "stale" attribute defines the ending time of the event's validity
interval. The start and stale fields together define an interval in time.
It has the same format as time and start.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute event/@how
type restriction of xs:string
properties
use required
facets
Kind Value Annotation
pattern \w(-\w+)*
annotation
documentation

format = character-character

    The "how" attribute gives a hint about how the coordinates were
    generated.  It is used specifically to relay a hint about the
    types of errors that may be expected in the data and to weight the
    data in systems that fuse multiple inputs.  For example,
    coordinates transcribed by humans may have digit transposition,
    missing or repeated digits, estimated error bounds, etc.  As such,
    they may require special attention as they propagate through the
    kill chain (e.g., they may require an additional review).
    Similarly, machine generated coordinates derived solely from
    magnetic sources may be subject to known anomalies in certain
    geographical areas, etc.

        h - human entered or modified (someone typed the coordinates)
            e - estimated (a swag by the user)
            c - calculated (user probably calculated value by hand)
            t - transcribed (from voice, paper, ...)
            p - cut and paste from another window
        m - machine generated
            i - mensurated (from imagery)
            g - derived from GPS receiver
            m - magnetic    - derived from magnetic sources
            s - simulated   - out of a simulation
            f - fused       - corroborated from multiple sources
            c - configured  - out of a configuration file
            p - predicted   - prediction of future (e.g., a from a tracker)
            r - relayed     - imported from another system (gateway)

  As with other compound fields, the elements of the how field
  will be delimited by the field separator character "-".  E.g,
  A coordinate mensurated from imagery would have a how field of "m-i".
source <xs:attribute name="how" use="required">
 
<xs:annotation>
   
<xs:documentation>
format = character-character

    The "how" attribute gives a hint about how the coordinates were
    generated.  It is used specifically to relay a hint about the
    types of errors that may be expected in the data and to weight the
    data in systems that fuse multiple inputs.  For example,
    coordinates transcribed by humans may have digit transposition,
    missing or repeated digits, estimated error bounds, etc.  As such,
    they may require special attention as they propagate through the
    kill chain (e.g., they may require an additional review).
    Similarly, machine generated coordinates derived solely from
    magnetic sources may be subject to known anomalies in certain
    geographical areas, etc.

        h - human entered or modified (someone typed the coordinates)
            e - estimated (a swag by the user)
            c - calculated (user probably calculated value by hand)
            t - transcribed (from voice, paper, ...)
            p - cut and paste from another window
        m - machine generated
            i - mensurated (from imagery)
            g - derived from GPS receiver
            m - magnetic    - derived from magnetic sources
            s - simulated   - out of a simulation
            f - fused       - corroborated from multiple sources
            c - configured  - out of a configuration file
            p - predicted   - prediction of future (e.g., a from a tracker)
            r - relayed     - imported from another system (gateway)

  As with other compound fields, the elements of the how field
  will be delimited by the field separator character "-".  E.g,
  A coordinate mensurated from imagery would have a how field of "m-i".
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:string">
     
<xs:pattern value="\w(-\w+)*"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

element point
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p4.png
properties
content complex
used by
elements CursorOnTarget event
attributes
Name  Type  Use  Default  Fixed  Annotation
lat  derived by: xs:decimal  required      
documentation
Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90.
lon  derived by: xs:decimal  required      
documentation
Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180.
hae  xs:decimal  required      
documentation
HAE acronym for Height above Ellipsoid based on WGS-84 ellipsoid (measured in meters).
ce  xs:decimal  required      
documentation

Circular Error around point defined by lat and lon fields in meters. Although
named ce, this field is intended to define a circular area around the event point, not
necessarily an error (e.g. Describing a reservation area is not an
"error").  If it is appropriate for the "ce" field to represent
an error value (e.g. event describes laser designated target), the
value will represent the one sigma point for a zero mean
normal (Guassian) distribution.
le  xs:decimal  required      
documentation

Linear Error in meters associated with the HAE field. Although named le, this
field is intended to define a height range about the event point, not
necessarily an error. This field, along with the ce field allow for the
definition of a cylindrical volume about the point. If it is appropriate
for the "le" field to represent an error (e.g. event describes laser
designated target), the value will represent the one sigma point for
a zero mean normal (Guassian) distribution.
source <xs:element name="point">
 
<xs:complexType>
   
<xs:attribute name="lat" use="required">
     
<xs:annotation>
       
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-90"/>
         
<xs:maxInclusive value="90"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="lon" use="required">
     
<xs:annotation>
       
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-180"/>
         
<xs:maxInclusive value="180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="hae" type="xs:decimal" use="required">
     
<xs:annotation>
       
<xs:documentation>HAE acronym for Height above Ellipsoid based on WGS-84 ellipsoid (measured in meters).</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="ce" type="xs:decimal" use="required">
     
<xs:annotation>
       
<xs:documentation>
Circular Error around point defined by lat and lon fields in meters. Although
named ce, this field is intended to define a circular area around the event point, not
necessarily an error (e.g. Describing a reservation area is not an
"error").  If it is appropriate for the "ce" field to represent
an error value (e.g. event describes laser designated target), the
value will represent the one sigma point for a zero mean
normal (Guassian) distribution.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="le" type="xs:decimal" use="required">
     
<xs:annotation>
       
<xs:documentation>
Linear Error in meters associated with the HAE field. Although named le, this
field is intended to define a height range about the event point, not
necessarily an error. This field, along with the ce field allow for the
definition of a cylindrical volume about the point. If it is appropriate
for the "le" field to represent an error (e.g. event describes laser
designated target), the value will represent the one sigma point for
a zero mean normal (Guassian) distribution.
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute point/@lat
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive -90
maxInclusive 90
annotation
documentation
Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90.
source <xs:attribute name="lat" use="required">
 
<xs:annotation>
   
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-90"/>
     
<xs:maxInclusive value="90"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute point/@lon
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive -180
maxInclusive 180
annotation
documentation
Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180.
source <xs:attribute name="lon" use="required">
 
<xs:annotation>
   
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-180"/>
     
<xs:maxInclusive value="180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute point/@hae
type xs:decimal
properties
use required
annotation
documentation
HAE acronym for Height above Ellipsoid based on WGS-84 ellipsoid (measured in meters).
source <xs:attribute name="hae" type="xs:decimal" use="required">
 
<xs:annotation>
   
<xs:documentation>HAE acronym for Height above Ellipsoid based on WGS-84 ellipsoid (measured in meters).</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute point/@ce
type xs:decimal
properties
use required
annotation
documentation

Circular Error around point defined by lat and lon fields in meters. Although
named ce, this field is intended to define a circular area around the event point, not
necessarily an error (e.g. Describing a reservation area is not an
"error").  If it is appropriate for the "ce" field to represent
an error value (e.g. event describes laser designated target), the
value will represent the one sigma point for a zero mean
normal (Guassian) distribution.
source <xs:attribute name="ce" type="xs:decimal" use="required">
 
<xs:annotation>
   
<xs:documentation>
Circular Error around point defined by lat and lon fields in meters. Although
named ce, this field is intended to define a circular area around the event point, not
necessarily an error (e.g. Describing a reservation area is not an
"error").  If it is appropriate for the "ce" field to represent
an error value (e.g. event describes laser designated target), the
value will represent the one sigma point for a zero mean
normal (Guassian) distribution.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute point/@le
type xs:decimal
properties
use required
annotation
documentation

Linear Error in meters associated with the HAE field. Although named le, this
field is intended to define a height range about the event point, not
necessarily an error. This field, along with the ce field allow for the
definition of a cylindrical volume about the point. If it is appropriate
for the "le" field to represent an error (e.g. event describes laser
designated target), the value will represent the one sigma point for
a zero mean normal (Guassian) distribution.
source <xs:attribute name="le" type="xs:decimal" use="required">
 
<xs:annotation>
   
<xs:documentation>
Linear Error in meters associated with the HAE field. Although named le, this
field is intended to define a height range about the event point, not
necessarily an error. This field, along with the ce field allow for the
definition of a cylindrical volume about the point. If it is appropriate
for the "le" field to represent an error (e.g. event describes laser
designated target), the value will represent the one sigma point for
a zero mean normal (Guassian) distribution.
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element contact
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p5.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
callsign  xs:string  optional      
documentation
The unit's voice call sign
freq  xs:decimal  optional      
documentation
The frequency (in MHz) on which the unit may be contacted via voice.
email  xs:string  optional      
documentation
e-mail address for this element (if applicable)
dsn  xs:string  optional      
documentation
DSN number for this element (if applicable)
phone  xs:string  optional      
documentation
Phone number for this element (if applicable)
modulation  xs:string  optional      
documentation
Amplifies the radio frequency information provided.  Contains the modulation type for the communication.  (Coding tbd, should cover complex modulations such as SINCGARS hopping, csma, etc...) am|fm
hostname  xs:string  optional      
documentation
DNS-resolvable host name
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
annotation
documentation
This is a Cursor On Target sub-schema representing communications parameters for contacting a friendly element for human-to-human communcations. The objective of this schema is to carry the essential information needed to contact this entity by a variety of means.  None of the modes of contact (e.g., e-mail, phone, etc) is required.
source <xs:element name="contact">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema representing communications parameters for contacting a friendly element for human-to-human communcations. The objective of this schema is to carry the essential information needed to contact this entity by a variety of means.  None of the modes of contact (e.g., e-mail, phone, etc) is required.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="callsign" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>The unit's voice call sign</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="freq" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>The frequency (in MHz) on which the unit may be contacted via voice.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="email" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>e-mail address for this element (if applicable)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="dsn" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>DSN number for this element (if applicable)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="phone" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Phone number for this element (if applicable)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="modulation" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Amplifies the radio frequency information provided.  Contains the modulation type for the communication.  (Coding tbd, should cover complex modulations such as SINCGARS hopping, csma, etc...) am|fm</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="hostname" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>DNS-resolvable host name</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute contact/@callsign
type xs:string
properties
use optional
annotation
documentation
The unit's voice call sign
source <xs:attribute name="callsign" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>The unit's voice call sign</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@freq
type xs:decimal
properties
use optional
annotation
documentation
The frequency (in MHz) on which the unit may be contacted via voice.
source <xs:attribute name="freq" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>The frequency (in MHz) on which the unit may be contacted via voice.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@email
type xs:string
properties
use optional
annotation
documentation
e-mail address for this element (if applicable)
source <xs:attribute name="email" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>e-mail address for this element (if applicable)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@dsn
type xs:string
properties
use optional
annotation
documentation
DSN number for this element (if applicable)
source <xs:attribute name="dsn" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>DSN number for this element (if applicable)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@phone
type xs:string
properties
use optional
annotation
documentation
Phone number for this element (if applicable)
source <xs:attribute name="phone" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Phone number for this element (if applicable)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@modulation
type xs:string
properties
use optional
annotation
documentation
Amplifies the radio frequency information provided.  Contains the modulation type for the communication.  (Coding tbd, should cover complex modulations such as SINCGARS hopping, csma, etc...) am|fm
source <xs:attribute name="modulation" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Amplifies the radio frequency information provided.  Contains the modulation type for the communication.  (Coding tbd, should cover complex modulations such as SINCGARS hopping, csma, etc...) am|fm</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@hostname
type xs:string
properties
use optional
annotation
documentation
DNS-resolvable host name
source <xs:attribute name="hostname" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>DNS-resolvable host name</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute contact/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element _flow-tags_
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p6.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
version  xs:decimal  optional      
annotation
documentation
This is a Cursor On Target detail sub-schema that holds "fingerprints" of the system that have processed a particular CoT event.  This information aids in the routine of CoT messages along a particular processing chain.  Each system that touches a particular CoT event is expected to add its own attribute to this entity.  The attribute name should reflect the particular system name, and the value should be the time stamp when the information was sent out from that system.  Some illustrative _flow-tags_ attributes are adocs, fbcb2, and tadilj, but the attribute list is not a closed set.
source <xs:element name="_flow-tags_">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target detail sub-schema that holds "fingerprints" of the system that have processed a particular CoT event.  This information aids in the routine of CoT messages along a particular processing chain.  Each system that touches a particular CoT event is expected to add its own attribute to this entity.  The attribute name should reflect the particular system name, and the value should be the time stamp when the information was sent out from that system.  Some illustrative _flow-tags_ attributes are adocs, fbcb2, and tadilj, but the attribute list is not a closed set.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="version" type="xs:decimal" use="optional"/>
   
<xs:anyAttribute processContents="lax">
     
<xs:annotation>
       
<xs:documentation>A system-specific flowtag identifier associated with the encapsulating CoT object. The attribute value should be an xs:dateTime value.</xs:documentation>
     
</xs:annotation>
   
</xs:anyAttribute>
 
</xs:complexType>
</xs:element>

attribute _flow-tags_/@version
type xs:decimal
properties
use optional
source <xs:attribute name="version" type="xs:decimal" use="optional"/>

element image
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p7.png
properties
content complex
mixed true
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
type  xs:string  optional      
documentation
Image type, drawn from NITF specification.  E.g., SL - side-looking radar, TI - thermal infrared, FL - forward looking infrared, RD - radar, EO - electro-optical, OP - optical, HR - high resolution radar, HS - hyperspectral, CP - color frame photography, BP - black/white frame photography, SAR - synthetic aperture radar, SARIQ - SAR radio hologram, IR - infrared, MS - multispectral, ...
georegistered  xs:boolean  optional      
documentation
(DEPRECATED) True if this image has been properly geo-registered
source  xs:string  optional      
documentation
(REVISED) The source of this image, specifically the CoT UID of the producer. (The intention is to indicate equipment type used to collect imagery, not organization owning image.)
resolution  xs:decimal  optional      
documentation
Image product resolution (expressed in meters per pixel)
url  xs:anyURI  optional      
documentation
URL link to image if the image is not embedded
fov  derived by: xs:decimal  optional      
documentation
(REVISED) Approximate angular field of view (degrees)
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
size  xs:nonNegativeInteger  optional      
documentation
Approximate image file size (bytes)
analysis  xs:boolean  optional      
documentation
(DEPRECATED) True if image analysis (e.g., markup) is available
mime  xs:string  required      
documentation
If an in-lined image is contained in this entity, then this attribute describes the mime type of that image.  The actual image data will be base64 encoded. See http://www.w3schools.com/media/media_mimeref.asp for list of common mime types.
width  xs:nonNegativeInteger  optional      
documentation
The width of the image (in pixels)
height  xs:nonNegativeInteger  optional      
documentation
The height of the image (in pixels)
reason  xs:string  optional      
documentation
(NEW) The reason this image was originally produced (BHA, BDA, ISR, ...)  Coding is TBD but will reflect the CoT type coding structure.  E.g., a-d-b Assesment-Damage-Bomb, etc...
bands  xs:nonNegativeInteger  optional      
documentation
Number of data bands within the image. For example, an RGB image as 3 bands (Red, Green, Blue bands/channels)
mimecsv  xs:string  optional      
documentation
Used only if the attribute 'mime' references a container type (e.g., image/x-nitf21).  In this case, 'mimecsv' holds a list of Comma Separated Values to supplement the MIME type in the mime field.  Nominally, the values in 'mimecsv' wil lbe mime types of the elements in the composite image.  For example, if 'mime' 'image/x-nitf21', then 'mimecsv' may hold 'image/jpeg', 'image/jpeg2000', or 'image/x-eagleeye'.
north  derived by: xs:decimal  optional      
documentation
Indicates the orientation of 'north' (true) on the image.  This is an angular measure in degrees.  Zero indicates that the north arrow would point up (towards 12 o'clock) on the image, 90 indicates that the the north arrow would point right (3 o'clock).
quality  xs:string  optional      
documentation
This expresses how the tradeoff between image quality and compression were made for this image.  This is usually a 'relative' quality measure, an unsigned floating point value between 0.0 (highest compression) and 1.0 (highest quality). Implementers should attempt to map this scalar value to an approximate linear progression of visual quality as determined on a typical sample image.  If the field's value carries an explicit sign (+/-) including +0 or -0, it represents the exact value expressed in a range appropriate to the compression type expressed in 'mime' or 'mimecsv'.  For example,  with 'image/x-eagleeye' the EagleEye clip setting, the quality setting may range from -4096.0 to +4096.0.
annotation
documentation
This is a Cursor On Target sub-schema for abstract image product metadata. It is specifically limited to geographically located (though not necessarily geographically registered) image products.  It is not intended to contain all the meta data typically found in the NITF header associated with such images, but rather provides sufficient "hints" about the ISR product to facilitate collection queuing and ipl searching.  Full meta data will reside in the NITF header or other IPL-specific schemas.  This sub schema borrows from the NITF standard.  Note, also, that this subschema presumes is is contained within a CoT base element which provides information about center poiint, etc.  Similarly, the CoT_shape schema can be used to delimit the bounds of the image.  Furthermore, this element may conatin a base64 encoded image file.  In this case, the 'mime' attribute should indicate the image type.
source <xs:element name="image">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for abstract image product metadata. It is specifically limited to geographically located (though not necessarily geographically registered) image products.  It is not intended to contain all the meta data typically found in the NITF header associated with such images, but rather provides sufficient "hints" about the ISR product to facilitate collection queuing and ipl searching.  Full meta data will reside in the NITF header or other IPL-specific schemas.  This sub schema borrows from the NITF standard.  Note, also, that this subschema presumes is is contained within a CoT base element which provides information about center poiint, etc.  Similarly, the CoT_shape schema can be used to delimit the bounds of the image.  Furthermore, this element may conatin a base64 encoded image file.  In this case, the 'mime' attribute should indicate the image type.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType mixed="true">
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="type" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Image type, drawn from NITF specification.  E.g., SL - side-looking radar, TI - thermal infrared, FL - forward looking infrared, RD - radar, EO - electro-optical, OP - optical, HR - high resolution radar, HS - hyperspectral, CP - color frame photography, BP - black/white frame photography, SAR - synthetic aperture radar, SARIQ - SAR radio hologram, IR - infrared, MS - multispectral, ...</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="georegistered" type="xs:boolean" use="optional">
     
<xs:annotation>
       
<xs:documentation>(DEPRECATED) True if this image has been properly geo-registered</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="source" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>(REVISED) The source of this image, specifically the CoT UID of the producer. (The intention is to indicate equipment type used to collect imagery, not organization owning image.)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="resolution" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Image product resolution (expressed in meters per pixel)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="url" type="xs:anyURI" use="optional">
     
<xs:annotation>
       
<xs:documentation>URL link to image if the image is not embedded</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="fov" use="optional">
     
<xs:annotation>
       
<xs:documentation>(REVISED) Approximate angular field of view (degrees)</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="size" type="xs:nonNegativeInteger" use="optional">
     
<xs:annotation>
       
<xs:documentation>Approximate image file size (bytes)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="analysis" type="xs:boolean" use="optional">
     
<xs:annotation>
       
<xs:documentation>(DEPRECATED) True if image analysis (e.g., markup) is available</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="mime" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>If an in-lined image is contained in this entity, then this attribute describes the mime type of that image.  The actual image data will be base64 encoded. See http://www.w3schools.com/media/media_mimeref.asp for list of common mime types.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="width" type="xs:nonNegativeInteger" use="optional">
     
<xs:annotation>
       
<xs:documentation>The width of the image (in pixels)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="height" type="xs:nonNegativeInteger" use="optional">
     
<xs:annotation>
       
<xs:documentation>The height of the image (in pixels)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="reason" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>(NEW) The reason this image was originally produced (BHA, BDA, ISR, ...)  Coding is TBD but will reflect the CoT type coding structure.  E.g., a-d-b Assesment-Damage-Bomb, etc...</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="bands" type="xs:nonNegativeInteger" use="optional">
     
<xs:annotation>
       
<xs:documentation>Number of data bands within the image. For example, an RGB image as 3 bands (Red, Green, Blue bands/channels)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="mimecsv" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Used only if the attribute 'mime' references a container type (e.g., image/x-nitf21).  In this case, 'mimecsv' holds a list of Comma Separated Values to supplement the MIME type in the mime field.  Nominally, the values in 'mimecsv' wil lbe mime types of the elements in the composite image.  For example, if 'mime' 'image/x-nitf21', then 'mimecsv' may hold 'image/jpeg', 'image/jpeg2000', or 'image/x-eagleeye'.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="north" use="optional">
     
<xs:annotation>
       
<xs:documentation>Indicates the orientation of 'north' (true) on the image.  This is an angular measure in degrees.  Zero indicates that the north arrow would point up (towards 12 o'clock) on the image, 90 indicates that the the north arrow would point right (3 o'clock).</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="quality" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>This expresses how the tradeoff between image quality and compression were made for this image.  This is usually a 'relative' quality measure, an unsigned floating point value between 0.0 (highest compression) and 1.0 (highest quality). Implementers should attempt to map this scalar value to an approximate linear progression of visual quality as determined on a typical sample image.  If the field's value carries an explicit sign (+/-) including +0 or -0, it represents the exact value expressed in a range appropriate to the compression type expressed in 'mime' or 'mimecsv'.  For example,  with 'image/x-eagleeye' the EagleEye clip setting, the quality setting may range from -4096.0 to +4096.0.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute image/@type
type xs:string
properties
use optional
annotation
documentation
Image type, drawn from NITF specification.  E.g., SL - side-looking radar, TI - thermal infrared, FL - forward looking infrared, RD - radar, EO - electro-optical, OP - optical, HR - high resolution radar, HS - hyperspectral, CP - color frame photography, BP - black/white frame photography, SAR - synthetic aperture radar, SARIQ - SAR radio hologram, IR - infrared, MS - multispectral, ...
source <xs:attribute name="type" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Image type, drawn from NITF specification.  E.g., SL - side-looking radar, TI - thermal infrared, FL - forward looking infrared, RD - radar, EO - electro-optical, OP - optical, HR - high resolution radar, HS - hyperspectral, CP - color frame photography, BP - black/white frame photography, SAR - synthetic aperture radar, SARIQ - SAR radio hologram, IR - infrared, MS - multispectral, ...</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@georegistered
type xs:boolean
properties
use optional
annotation
documentation
(DEPRECATED) True if this image has been properly geo-registered
source <xs:attribute name="georegistered" type="xs:boolean" use="optional">
 
<xs:annotation>
   
<xs:documentation>(DEPRECATED) True if this image has been properly geo-registered</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@source
type xs:string
properties
use optional
annotation
documentation
(REVISED) The source of this image, specifically the CoT UID of the producer. (The intention is to indicate equipment type used to collect imagery, not organization owning image.)
source <xs:attribute name="source" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>(REVISED) The source of this image, specifically the CoT UID of the producer. (The intention is to indicate equipment type used to collect imagery, not organization owning image.)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@resolution
type xs:decimal
properties
use optional
annotation
documentation
Image product resolution (expressed in meters per pixel)
source <xs:attribute name="resolution" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Image product resolution (expressed in meters per pixel)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@url
type xs:anyURI
properties
use optional
annotation
documentation
URL link to image if the image is not embedded
source <xs:attribute name="url" type="xs:anyURI" use="optional">
 
<xs:annotation>
   
<xs:documentation>URL link to image if the image is not embedded</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@fov
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
(REVISED) Approximate angular field of view (degrees)
source <xs:attribute name="fov" use="optional">
 
<xs:annotation>
   
<xs:documentation>(REVISED) Approximate angular field of view (degrees)</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute image/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@size
type xs:nonNegativeInteger
properties
use optional
annotation
documentation
Approximate image file size (bytes)
source <xs:attribute name="size" type="xs:nonNegativeInteger" use="optional">
 
<xs:annotation>
   
<xs:documentation>Approximate image file size (bytes)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@analysis
type xs:boolean
properties
use optional
annotation
documentation
(DEPRECATED) True if image analysis (e.g., markup) is available
source <xs:attribute name="analysis" type="xs:boolean" use="optional">
 
<xs:annotation>
   
<xs:documentation>(DEPRECATED) True if image analysis (e.g., markup) is available</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@mime
type xs:string
properties
use required
annotation
documentation
If an in-lined image is contained in this entity, then this attribute describes the mime type of that image.  The actual image data will be base64 encoded. See http://www.w3schools.com/media/media_mimeref.asp for list of common mime types.
source <xs:attribute name="mime" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>If an in-lined image is contained in this entity, then this attribute describes the mime type of that image.  The actual image data will be base64 encoded. See http://www.w3schools.com/media/media_mimeref.asp for list of common mime types.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@width
type xs:nonNegativeInteger
properties
use optional
annotation
documentation
The width of the image (in pixels)
source <xs:attribute name="width" type="xs:nonNegativeInteger" use="optional">
 
<xs:annotation>
   
<xs:documentation>The width of the image (in pixels)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@height
type xs:nonNegativeInteger
properties
use optional
annotation
documentation
The height of the image (in pixels)
source <xs:attribute name="height" type="xs:nonNegativeInteger" use="optional">
 
<xs:annotation>
   
<xs:documentation>The height of the image (in pixels)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@reason
type xs:string
properties
use optional
annotation
documentation
(NEW) The reason this image was originally produced (BHA, BDA, ISR, ...)  Coding is TBD but will reflect the CoT type coding structure.  E.g., a-d-b Assesment-Damage-Bomb, etc...
source <xs:attribute name="reason" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>(NEW) The reason this image was originally produced (BHA, BDA, ISR, ...)  Coding is TBD but will reflect the CoT type coding structure.  E.g., a-d-b Assesment-Damage-Bomb, etc...</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@bands
type xs:nonNegativeInteger
properties
use optional
annotation
documentation
Number of data bands within the image. For example, an RGB image as 3 bands (Red, Green, Blue bands/channels)
source <xs:attribute name="bands" type="xs:nonNegativeInteger" use="optional">
 
<xs:annotation>
   
<xs:documentation>Number of data bands within the image. For example, an RGB image as 3 bands (Red, Green, Blue bands/channels)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@mimecsv
type xs:string
properties
use optional
annotation
documentation
Used only if the attribute 'mime' references a container type (e.g., image/x-nitf21).  In this case, 'mimecsv' holds a list of Comma Separated Values to supplement the MIME type in the mime field.  Nominally, the values in 'mimecsv' wil lbe mime types of the elements in the composite image.  For example, if 'mime' 'image/x-nitf21', then 'mimecsv' may hold 'image/jpeg', 'image/jpeg2000', or 'image/x-eagleeye'.
source <xs:attribute name="mimecsv" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Used only if the attribute 'mime' references a container type (e.g., image/x-nitf21).  In this case, 'mimecsv' holds a list of Comma Separated Values to supplement the MIME type in the mime field.  Nominally, the values in 'mimecsv' wil lbe mime types of the elements in the composite image.  For example, if 'mime' 'image/x-nitf21', then 'mimecsv' may hold 'image/jpeg', 'image/jpeg2000', or 'image/x-eagleeye'.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute image/@north
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
Indicates the orientation of 'north' (true) on the image.  This is an angular measure in degrees.  Zero indicates that the north arrow would point up (towards 12 o'clock) on the image, 90 indicates that the the north arrow would point right (3 o'clock).
source <xs:attribute name="north" use="optional">
 
<xs:annotation>
   
<xs:documentation>Indicates the orientation of 'north' (true) on the image.  This is an angular measure in degrees.  Zero indicates that the north arrow would point up (towards 12 o'clock) on the image, 90 indicates that the the north arrow would point right (3 o'clock).</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute image/@quality
type xs:string
properties
use optional
annotation
documentation
This expresses how the tradeoff between image quality and compression were made for this image.  This is usually a 'relative' quality measure, an unsigned floating point value between 0.0 (highest compression) and 1.0 (highest quality). Implementers should attempt to map this scalar value to an approximate linear progression of visual quality as determined on a typical sample image.  If the field's value carries an explicit sign (+/-) including +0 or -0, it represents the exact value expressed in a range appropriate to the compression type expressed in 'mime' or 'mimecsv'.  For example,  with 'image/x-eagleeye' the EagleEye clip setting, the quality setting may range from -4096.0 to +4096.0.
source <xs:attribute name="quality" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>This expresses how the tradeoff between image quality and compression were made for this image.  This is usually a 'relative' quality measure, an unsigned floating point value between 0.0 (highest compression) and 1.0 (highest quality). Implementers should attempt to map this scalar value to an approximate linear progression of visual quality as determined on a typical sample image.  If the field's value carries an explicit sign (+/-) including +0 or -0, it represents the exact value expressed in a range appropriate to the compression type expressed in 'mime' or 'mimecsv'.  For example,  with 'image/x-eagleeye' the EagleEye clip setting, the quality setting may range from -4096.0 to +4096.0.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element link
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p8.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
relation  xs:string  required      
documentation
The type of relationship (e.g, subject, object, indirect object) that this link describes.  This is a hierarchy much like the event type field.
uid  xs:string  required      
documentation
This is the CoT UID of the related object. If the linked object is not a CoT event, a CoT UID that represents that object is used.
type  xs:string  required      
documentation
The CoT type of the referenced object.  This is included because it is generally the key item needed in a tasking.
url  xs:string  optional      
documentation
If present, this is a URL through which the linked object can be retrieved.   If the URL is missing, then the object should be a periodic message (e.g., blue force track) that can be read from a CoT stream.
remarks  xs:string  optional      
documentation
Remarks associated with this link.
mime  xs:string  optional      
documentation
Internet Media type of the referenced object.  If the link is to a CoT event, the mime attribute is optional and its type may be application/xml or text/xml as described in RFC 3023, "XML Media Types", or the unregistered type, application/cot+xml.  If the link is to an arbitrary resource, the mime attribute is required and and appropriate Internet media type must be specified.  Registered media types are managed by the IANA and are listed at http://www.iana.org/assignments/media-types/.
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
annotation
documentation
This is a Cursor On Target sub-schema for linking to either another CoT event or an arbitrary Internet resource. The objective of this schema is to provide an abstract way to express a relationship between a CoT object and other object.  This allows, for example, a sensor point of interest to be linked back to its source, or a PPLI from a wingman to be associated with his flight lead.  Linkages are always unidirectional.  One entity may have multiple links (i.e., it may be related to multipls other entities).  For processing simplicity, it is required that the relationship graphs will directed and acyclic (no cycles).  The link, itself, names the relationship (using a hierarchy similiar to the CoT type), the UID of the related object (whether CoT or not), possibly provides a URL for retrieving that object.
source <xs:element name="link">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for linking to either another CoT event or an arbitrary Internet resource. The objective of this schema is to provide an abstract way to express a relationship between a CoT object and other object.  This allows, for example, a sensor point of interest to be linked back to its source, or a PPLI from a wingman to be associated with his flight lead.  Linkages are always unidirectional.  One entity may have multiple links (i.e., it may be related to multipls other entities).  For processing simplicity, it is required that the relationship graphs will directed and acyclic (no cycles).  The link, itself, names the relationship (using a hierarchy similiar to the CoT type), the UID of the related object (whether CoT or not), possibly provides a URL for retrieving that object.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="relation" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>The type of relationship (e.g, subject, object, indirect object) that this link describes.  This is a hierarchy much like the event type field.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="uid" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>This is the CoT UID of the related object. If the linked object is not a CoT event, a CoT UID that represents that object is used.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="type" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>The CoT type of the referenced object.  This is included because it is generally the key item needed in a tasking.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="url" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>If present, this is a URL through which the linked object can be retrieved.   If the URL is missing, then the object should be a periodic message (e.g., blue force track) that can be read from a CoT stream.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="remarks" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Remarks associated with this link.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="mime" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Internet Media type of the referenced object.  If the link is to a CoT event, the mime attribute is optional and its type may be application/xml or text/xml as described in RFC 3023, "XML Media Types", or the unregistered type, application/cot+xml.  If the link is to an arbitrary resource, the mime attribute is required and and appropriate Internet media type must be specified.  Registered media types are managed by the IANA and are listed at http://www.iana.org/assignments/media-types/.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute link/@relation
type xs:string
properties
use required
annotation
documentation
The type of relationship (e.g, subject, object, indirect object) that this link describes.  This is a hierarchy much like the event type field.
source <xs:attribute name="relation" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>The type of relationship (e.g, subject, object, indirect object) that this link describes.  This is a hierarchy much like the event type field.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@uid
type xs:string
properties
use required
annotation
documentation
This is the CoT UID of the related object. If the linked object is not a CoT event, a CoT UID that represents that object is used.
source <xs:attribute name="uid" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>This is the CoT UID of the related object. If the linked object is not a CoT event, a CoT UID that represents that object is used.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@type
type xs:string
properties
use required
annotation
documentation
The CoT type of the referenced object.  This is included because it is generally the key item needed in a tasking.
source <xs:attribute name="type" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>The CoT type of the referenced object.  This is included because it is generally the key item needed in a tasking.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@url
type xs:string
properties
use optional
annotation
documentation
If present, this is a URL through which the linked object can be retrieved.   If the URL is missing, then the object should be a periodic message (e.g., blue force track) that can be read from a CoT stream.
source <xs:attribute name="url" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>If present, this is a URL through which the linked object can be retrieved.   If the URL is missing, then the object should be a periodic message (e.g., blue force track) that can be read from a CoT stream.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@remarks
type xs:string
properties
use optional
annotation
documentation
Remarks associated with this link.
source <xs:attribute name="remarks" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Remarks associated with this link.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@mime
type xs:string
properties
use optional
annotation
documentation
Internet Media type of the referenced object.  If the link is to a CoT event, the mime attribute is optional and its type may be application/xml or text/xml as described in RFC 3023, "XML Media Types", or the unregistered type, application/cot+xml.  If the link is to an arbitrary resource, the mime attribute is required and and appropriate Internet media type must be specified.  Registered media types are managed by the IANA and are listed at http://www.iana.org/assignments/media-types/.
source <xs:attribute name="mime" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Internet Media type of the referenced object.  If the link is to a CoT event, the mime attribute is optional and its type may be application/xml or text/xml as described in RFC 3023, "XML Media Types", or the unregistered type, application/cot+xml.  If the link is to an arbitrary resource, the mime attribute is required and and appropriate Internet media type must be specified.  Registered media types are managed by the IANA and are listed at http://www.iana.org/assignments/media-types/.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute link/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element remarks
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p9.png
properties
content complex
mixed true
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
source  xs:string  optional      
documentation
String identifying the source of this remark. (Field encoding is currently unspecified.)
time  xs:dateTime  optional      
documentation
Time this remark was added to the CoT object
to  xs:string  optional      
documentation
Intended recipeint(s) of this remark information. Tentative field coding as follows: The to attribute may contain the UID of the entity to whom the message is addressed.  (Implementors should expect that future versions of this sub schema will allow a comma separated list of UIDs.)  Absense of an explict addressee means the message is broadcast.
keywords  derived by: xs:string  optional      
documentation
Used to track a conversation thread.  The format is a comma-separated list of freetext keywords.

               ex. keywords="debriefing"            - Describes a conversation about debriefing
               ex. keywords="mission-A"             - Describes a conversation about mission-A
               ex. keywords="tasking_B, subject_C"  - Describes a conversation about tasking_B and subject_C
              
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
annotation
documentation
This is a Cursor On Target sub-schema for a generic remarks (aka "FreeText").  While the use of free text is strongly discouraged (it hampers machine-to-machine communication) it is a pragmatic necessity.  This entity attempts to encapsulate freetext in a way that simplifies subsequent machine processing.  The content of this entity is presumed to be a human-readable chunk of textual data.  The attributes merely aid in the machine handling of the data.
source <xs:element name="remarks">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for a generic remarks (aka "FreeText").  While the use of free text is strongly discouraged (it hampers machine-to-machine communication) it is a pragmatic necessity.  This entity attempts to encapsulate freetext in a way that simplifies subsequent machine processing.  The content of this entity is presumed to be a human-readable chunk of textual data.  The attributes merely aid in the machine handling of the data.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType mixed="true">
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="source" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>String identifying the source of this remark. (Field encoding is currently unspecified.)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="time" type="xs:dateTime" use="optional">
     
<xs:annotation>
       
<xs:documentation>Time this remark was added to the CoT object</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="to" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>Intended recipeint(s) of this remark information. Tentative field coding as follows: The to attribute may contain the UID of the entity to whom the message is addressed.  (Implementors should expect that future versions of this sub schema will allow a comma separated list of UIDs.)  Absense of an explict addressee means the message is broadcast.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="keywords" use="optional">
     
<xs:annotation>
       
<xs:documentation>Used to track a conversation thread.  The format is a comma-separated list of freetext keywords.

               ex. keywords="debriefing"            - Describes a conversation about debriefing
               ex. keywords="mission-A"             - Describes a conversation about mission-A
               ex. keywords="tasking_B, subject_C"  - Describes a conversation about tasking_B and subject_C
              
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:string">
         
<xs:pattern value="[\w\- ]+(,[\w\- ]+)*"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute remarks/@source
type xs:string
properties
use optional
annotation
documentation
String identifying the source of this remark. (Field encoding is currently unspecified.)
source <xs:attribute name="source" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>String identifying the source of this remark. (Field encoding is currently unspecified.)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute remarks/@time
type xs:dateTime
properties
use optional
annotation
documentation
Time this remark was added to the CoT object
source <xs:attribute name="time" type="xs:dateTime" use="optional">
 
<xs:annotation>
   
<xs:documentation>Time this remark was added to the CoT object</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute remarks/@to
type xs:string
properties
use optional
annotation
documentation
Intended recipeint(s) of this remark information. Tentative field coding as follows: The to attribute may contain the UID of the entity to whom the message is addressed.  (Implementors should expect that future versions of this sub schema will allow a comma separated list of UIDs.)  Absense of an explict addressee means the message is broadcast.
source <xs:attribute name="to" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>Intended recipeint(s) of this remark information. Tentative field coding as follows: The to attribute may contain the UID of the entity to whom the message is addressed.  (Implementors should expect that future versions of this sub schema will allow a comma separated list of UIDs.)  Absense of an explict addressee means the message is broadcast.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute remarks/@keywords
type restriction of xs:string
properties
use optional
facets
Kind Value Annotation
pattern [\w\- ]+(,[\w\- ]+)*
annotation
documentation
Used to track a conversation thread.  The format is a comma-separated list of freetext keywords.

               ex. keywords="debriefing"            - Describes a conversation about debriefing
               ex. keywords="mission-A"             - Describes a conversation about mission-A
               ex. keywords="tasking_B, subject_C"  - Describes a conversation about tasking_B and subject_C
              
source <xs:attribute name="keywords" use="optional">
 
<xs:annotation>
   
<xs:documentation>Used to track a conversation thread.  The format is a comma-separated list of freetext keywords.

               ex. keywords="debriefing"            - Describes a conversation about debriefing
               ex. keywords="mission-A"             - Describes a conversation about mission-A
               ex. keywords="tasking_B, subject_C"  - Describes a conversation about tasking_B and subject_C
              
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:string">
     
<xs:pattern value="[\w\- ]+(,[\w\- ]+)*"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute remarks/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element request
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p10.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
notify  xs:string  required      
documentation
Network endpoint to which status notifications should be delivered. (A network endpoint is represented as an URL, e.g., tcp://hostname:port,  udp://hostname:port.   The previous format, host:port, e.g., 192.168.0.1:71556, is deprecated, but implementers should be aware that this format may be in use.
wilcoby  xs:dateTime  optional      
documentation
An optional field that requests the receiving system to provide a positive or negative akcnowledgement (WILCO/CANTCO) by a specific time.  This is used to ensure that deadline driven requests are made known to the operator.
priority  xs:string  optional      
documentation
This optional field indicates this request's relative priority with respect to other requests.  (At present, no specific coding scheme is in mandated, but a floating point value between 0.0(low) and 1.0(high) is in current (limited) use.)
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
to  xs:string  optional      
documentation
When present, this field contains the CoT UID of the specific entity who is being addressed.  It is assumed that all CoT entities that can provide a service are reported as friendly atoms.
authority  xs:string  optional      
documentation
This is a 'signature block' which holds the CoT uid of the entity which has uathorized the request.  The authorizing entity is not necessarily the originator of the request and might not be associated with the 'notify' field. Authority is intended to provide services (such as a striker) a mechanism to verify that the request has been approved.
streamto  xs:string  optional      
annotation
documentation
This is a Cursor On Target sub-schema for a generic request.  This schema contains information common to all requests, specifically where responses should be sent, the overall priority of the request, if immediate willco/cantco acknowledgement is needed, etc.  Detail infomration for specific request types are carried in sub-schemas nested within this one.
source <xs:element name="request">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for a generic request.  This schema contains information common to all requests, specifically where responses should be sent, the overall priority of the request, if immediate willco/cantco acknowledgement is needed, etc.  Detail infomration for specific request types are carried in sub-schemas nested within this one.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="notify" type="xs:string" use="required">
     
<xs:annotation>
       
<xs:documentation>Network endpoint to which status notifications should be delivered. (A network endpoint is represented as an URL, e.g., tcp://hostname:port,  udp://hostname:port.   The previous format, host:port, e.g., 192.168.0.1:71556, is deprecated, but implementers should be aware that this format may be in use.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="wilcoby" type="xs:dateTime" use="optional">
     
<xs:annotation>
       
<xs:documentation>An optional field that requests the receiving system to provide a positive or negative akcnowledgement (WILCO/CANTCO) by a specific time.  This is used to ensure that deadline driven requests are made known to the operator.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="priority" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>This optional field indicates this request's relative priority with respect to other requests.  (At present, no specific coding scheme is in mandated, but a floating point value between 0.0(low) and 1.0(high) is in current (limited) use.)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="to" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>When present, this field contains the CoT UID of the specific entity who is being addressed.  It is assumed that all CoT entities that can provide a service are reported as friendly atoms.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="authority" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>This is a 'signature block' which holds the CoT uid of the entity which has uathorized the request.  The authorizing entity is not necessarily the originator of the request and might not be associated with the 'notify' field. Authority is intended to provide services (such as a striker) a mechanism to verify that the request has been approved.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="streamto" type="xs:string" use="optional"/>
 
</xs:complexType>
</xs:element>

attribute request/@notify
type xs:string
properties
use required
annotation
documentation
Network endpoint to which status notifications should be delivered. (A network endpoint is represented as an URL, e.g., tcp://hostname:port,  udp://hostname:port.   The previous format, host:port, e.g., 192.168.0.1:71556, is deprecated, but implementers should be aware that this format may be in use.
source <xs:attribute name="notify" type="xs:string" use="required">
 
<xs:annotation>
   
<xs:documentation>Network endpoint to which status notifications should be delivered. (A network endpoint is represented as an URL, e.g., tcp://hostname:port,  udp://hostname:port.   The previous format, host:port, e.g., 192.168.0.1:71556, is deprecated, but implementers should be aware that this format may be in use.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@wilcoby
type xs:dateTime
properties
use optional
annotation
documentation
An optional field that requests the receiving system to provide a positive or negative akcnowledgement (WILCO/CANTCO) by a specific time.  This is used to ensure that deadline driven requests are made known to the operator.
source <xs:attribute name="wilcoby" type="xs:dateTime" use="optional">
 
<xs:annotation>
   
<xs:documentation>An optional field that requests the receiving system to provide a positive or negative akcnowledgement (WILCO/CANTCO) by a specific time.  This is used to ensure that deadline driven requests are made known to the operator.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@priority
type xs:string
properties
use optional
annotation
documentation
This optional field indicates this request's relative priority with respect to other requests.  (At present, no specific coding scheme is in mandated, but a floating point value between 0.0(low) and 1.0(high) is in current (limited) use.)
source <xs:attribute name="priority" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>This optional field indicates this request's relative priority with respect to other requests.  (At present, no specific coding scheme is in mandated, but a floating point value between 0.0(low) and 1.0(high) is in current (limited) use.)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@to
type xs:string
properties
use optional
annotation
documentation
When present, this field contains the CoT UID of the specific entity who is being addressed.  It is assumed that all CoT entities that can provide a service are reported as friendly atoms.
source <xs:attribute name="to" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>When present, this field contains the CoT UID of the specific entity who is being addressed.  It is assumed that all CoT entities that can provide a service are reported as friendly atoms.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@authority
type xs:string
properties
use optional
annotation
documentation
This is a 'signature block' which holds the CoT uid of the entity which has uathorized the request.  The authorizing entity is not necessarily the originator of the request and might not be associated with the 'notify' field. Authority is intended to provide services (such as a striker) a mechanism to verify that the request has been approved.
source <xs:attribute name="authority" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>This is a 'signature block' which holds the CoT uid of the entity which has uathorized the request.  The authorizing entity is not necessarily the originator of the request and might not be associated with the 'notify' field. Authority is intended to provide services (such as a striker) a mechanism to verify that the request has been approved.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute request/@streamto
type xs:string
properties
use optional
source <xs:attribute name="streamto" type="xs:string" use="optional"/>

element sensor
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p11.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
azimuth  derived by: xs:decimal  optional      
documentation
Direction (with respect to true north) that the sensor is pointed.  Azimuth is corrected for platform heading and attitude so an azimuth of 0 means the sensor is looking due north (albeit with some possible elevation)
elevation  derived by: xs:decimal  optional      
documentation
The vertical "tilt" of the sensor in degrees.  Zero is level (sensor looking at the horizon), positive indicates the sensor is elevated above the horizon.
roll  derived by: xs:decimal  optional      
documentation
Roll of sensor in degrees. A positive value indicates right-side down. 
          The intent of this attribute is to provide a means for reporting roll when it cannot be corrected
          with respect to the platform attitude.
         
          To visualize sensor roll, consider a fixed camera on an aircraft aimed straight ahead.
          When the aircraft is in a roll, the camera will rotate with the aircraft
          and the resulting image will be skewed.
fov  derived by: xs:decimal  optional      
documentation
This is an angular measure of the sensor's field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)
vfov  derived by: xs:decimal  optional      
documentation
This is an angular measure of the sensor's vertical field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)
north  derived by: xs:decimal  optional      
documentation
As sensor and platform orientation change, so does the apparent direction of "north" on the resulting sensor image.  This attribute indicates the orientation (in degrees clockwise) of a "north" arrow if it were painted on the image.  Zero indicates that the north arrow would be oriented "up" on the image, 90 indicates the north arrow would point to the right.
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
type  xs:string  optional      
documentation
The sensor type.   This is a type hierarchy much like the CoT type tree.  E.g., r - raster, r-e - raster EO, r-e-z-c - raster EO zoom continuous.  See types.txt for details
model  xs:string  optional      
documentation
This is the sensor model.  E.g., LANTRIN, TARPS, etc.
range  derived by: xs:decimal  optional      
documentation
Range to target (meters).  This is the distance from the image plane to the object occupying the center pixel of the image array.
annotation
documentation
This is (the root class of) a Cursor On Target sub-schema for a steerable, staring sensor such as EO, IR, or Radar sensor. The root class is intended to capture only information on the sensor's orientation and field of view is.  Details about it's spectrum, sensitivity, resolution, modality, performance, etc., shouldbe captured in a "derived" subschema for that particular type of sensor.  All orientation attributes associated with sensor are normalized to an geodedic frame of reference, removing platform factors such as roll, pitch, yaw, etc. Therefore an "azimuth" of 0 means the sensor is pointed north regardless of its platform heading or attitude.
source <xs:element name="sensor">
 
<xs:annotation>
   
<xs:documentation>This is (the root class of) a Cursor On Target sub-schema for a steerable, staring sensor such as EO, IR, or Radar sensor. The root class is intended to capture only information on the sensor's orientation and field of view is.  Details about it's spectrum, sensitivity, resolution, modality, performance, etc., shouldbe captured in a "derived" subschema for that particular type of sensor.  All orientation attributes associated with sensor are normalized to an geodedic frame of reference, removing platform factors such as roll, pitch, yaw, etc. Therefore an "azimuth" of 0 means the sensor is pointed north regardless of its platform heading or attitude.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="azimuth" use="optional">
     
<xs:annotation>
       
<xs:documentation>Direction (with respect to true north) that the sensor is pointed.  Azimuth is corrected for platform heading and attitude so an azimuth of 0 means the sensor is looking due north (albeit with some possible elevation)</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="elevation" use="optional">
     
<xs:annotation>
       
<xs:documentation>The vertical "tilt" of the sensor in degrees.  Zero is level (sensor looking at the horizon), positive indicates the sensor is elevated above the horizon.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-90"/>
         
<xs:maxInclusive value="90"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="roll" use="optional">
     
<xs:annotation>
       
<xs:documentation>Roll of sensor in degrees. A positive value indicates right-side down. 
          The intent of this attribute is to provide a means for reporting roll when it cannot be corrected
          with respect to the platform attitude.
         
          To visualize sensor roll, consider a fixed camera on an aircraft aimed straight ahead.
          When the aircraft is in a roll, the camera will rotate with the aircraft
          and the resulting image will be skewed.
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="-180"/>
         
<xs:maxInclusive value="180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="fov" use="optional">
     
<xs:annotation>
       
<xs:documentation>This is an angular measure of the sensor's field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="vfov" use="optional">
     
<xs:annotation>
       
<xs:documentation>This is an angular measure of the sensor's vertical field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="north" use="optional">
     
<xs:annotation>
       
<xs:documentation>As sensor and platform orientation change, so does the apparent direction of "north" on the resulting sensor image.  This attribute indicates the orientation (in degrees clockwise) of a "north" arrow if it were painted on the image.  Zero indicates that the north arrow would be oriented "up" on the image, 90 indicates the north arrow would point to the right.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="type" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>The sensor type.   This is a type hierarchy much like the CoT type tree.  E.g., r - raster, r-e - raster EO, r-e-z-c - raster EO zoom continuous.  See types.txt for details</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="model" type="xs:string" use="optional">
     
<xs:annotation>
       
<xs:documentation>This is the sensor model.  E.g., LANTRIN, TARPS, etc.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="range" use="optional">
     
<xs:annotation>
       
<xs:documentation>Range to target (meters).  This is the distance from the image plane to the object occupying the center pixel of the image array.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute sensor/@azimuth
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
Direction (with respect to true north) that the sensor is pointed.  Azimuth is corrected for platform heading and attitude so an azimuth of 0 means the sensor is looking due north (albeit with some possible elevation)
source <xs:attribute name="azimuth" use="optional">
 
<xs:annotation>
   
<xs:documentation>Direction (with respect to true north) that the sensor is pointed.  Azimuth is corrected for platform heading and attitude so an azimuth of 0 means the sensor is looking due north (albeit with some possible elevation)</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@elevation
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive -90
maxInclusive 90
annotation
documentation
The vertical "tilt" of the sensor in degrees.  Zero is level (sensor looking at the horizon), positive indicates the sensor is elevated above the horizon.
source <xs:attribute name="elevation" use="optional">
 
<xs:annotation>
   
<xs:documentation>The vertical "tilt" of the sensor in degrees.  Zero is level (sensor looking at the horizon), positive indicates the sensor is elevated above the horizon.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-90"/>
     
<xs:maxInclusive value="90"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@roll
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
maxInclusive 180
minExclusive -180
annotation
documentation
Roll of sensor in degrees. A positive value indicates right-side down. 
          The intent of this attribute is to provide a means for reporting roll when it cannot be corrected
          with respect to the platform attitude.
         
          To visualize sensor roll, consider a fixed camera on an aircraft aimed straight ahead.
          When the aircraft is in a roll, the camera will rotate with the aircraft
          and the resulting image will be skewed.
source <xs:attribute name="roll" use="optional">
 
<xs:annotation>
   
<xs:documentation>Roll of sensor in degrees. A positive value indicates right-side down. 
          The intent of this attribute is to provide a means for reporting roll when it cannot be corrected
          with respect to the platform attitude.
         
          To visualize sensor roll, consider a fixed camera on an aircraft aimed straight ahead.
          When the aircraft is in a roll, the camera will rotate with the aircraft
          and the resulting image will be skewed.
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="-180"/>
     
<xs:maxInclusive value="180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@fov
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
This is an angular measure of the sensor's field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)
source <xs:attribute name="fov" use="optional">
 
<xs:annotation>
   
<xs:documentation>This is an angular measure of the sensor's field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@vfov
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
This is an angular measure of the sensor's vertical field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)
source <xs:attribute name="vfov" use="optional">
 
<xs:annotation>
   
<xs:documentation>This is an angular measure of the sensor's vertical field of view (beam width) expressed in degrees.  (This measurement is made from visible edge to visible edge, not from center of field to edge.)</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@north
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
As sensor and platform orientation change, so does the apparent direction of "north" on the resulting sensor image.  This attribute indicates the orientation (in degrees clockwise) of a "north" arrow if it were painted on the image.  Zero indicates that the north arrow would be oriented "up" on the image, 90 indicates the north arrow would point to the right.
source <xs:attribute name="north" use="optional">
 
<xs:annotation>
   
<xs:documentation>As sensor and platform orientation change, so does the apparent direction of "north" on the resulting sensor image.  This attribute indicates the orientation (in degrees clockwise) of a "north" arrow if it were painted on the image.  Zero indicates that the north arrow would be oriented "up" on the image, 90 indicates the north arrow would point to the right.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute sensor/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute sensor/@type
type xs:string
properties
use optional
annotation
documentation
The sensor type.   This is a type hierarchy much like the CoT type tree.  E.g., r - raster, r-e - raster EO, r-e-z-c - raster EO zoom continuous.  See types.txt for details
source <xs:attribute name="type" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>The sensor type.   This is a type hierarchy much like the CoT type tree.  E.g., r - raster, r-e - raster EO, r-e-z-c - raster EO zoom continuous.  See types.txt for details</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute sensor/@model
type xs:string
properties
use optional
annotation
documentation
This is the sensor model.  E.g., LANTRIN, TARPS, etc.
source <xs:attribute name="model" type="xs:string" use="optional">
 
<xs:annotation>
   
<xs:documentation>This is the sensor model.  E.g., LANTRIN, TARPS, etc.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute sensor/@range
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive 0
annotation
documentation
Range to target (meters).  This is the distance from the image plane to the object occupying the center pixel of the image array.
source <xs:attribute name="range" use="optional">
 
<xs:annotation>
   
<xs:documentation>Range to target (meters).  This is the distance from the image plane to the object occupying the center pixel of the image array.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

element shape
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p12.png
properties
content complex
children ellipse polyline dxf
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Can be used to ensure upward compatibility with future revisions.
annotation
documentation
This is a Cursor On Target sub-schema for a generic shape description.  Many objects are not adequately represented by the simple "point" object in the CoT base schema.  However, it is counterproductive to burden all CoT applications to understand arbitrary shapes, so "shape" is an optional attribute that can be used to communicate between shape-aware apprications.  The "point" object in the base schema must still be populated and the CE and LE fields in the point entity must be set such that the point completely encloses the area described in any shape entity in the detail section.  (This is needed so that CoT applications can quickly filter out objects that are clearly outside an area of interest.
source <xs:element name="shape">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for a generic shape description.  Many objects are not adequately represented by the simple "point" object in the CoT base schema.  However, it is counterproductive to burden all CoT applications to understand arbitrary shapes, so "shape" is an optional attribute that can be used to communicate between shape-aware apprications.  The "point" object in the base schema must still be populated and the CE and LE fields in the point entity must be set such that the point completely encloses the area described in any shape entity in the detail section.  (This is needed so that CoT applications can quickly filter out objects that are clearly outside an area of interest.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:element name="ellipse" minOccurs="0">
       
<xs:annotation>
         
<xs:documentation>The "ellipse" is a common shape abstraction used by many geomanipulation applications; it is supported natively.</xs:documentation>
       
</xs:annotation>
       
<xs:complexType>
         
<xs:sequence>
           
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         
</xs:sequence>
         
<xs:attribute name="major" type="nonNegativeDecimal" use="required">
           
<xs:annotation>
             
<xs:documentation>Ellipse major axis (meters)</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
         
<xs:attribute name="minor" type="nonNegativeDecimal" use="required">
           
<xs:annotation>
             
<xs:documentation>Ellipse minor axis (meters)</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
         
<xs:attribute name="angle" type="xs:decimal" use="required">
           
<xs:annotation>
             
<xs:documentation>Orientation of major axis with respect to true north. </xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
         
<xs:attribute name="level" type="xs:integer" use="optional">
           
<xs:annotation>
             
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas. 
                For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher
                level value will be the "more desirable" representation of the object.  This allows producers to provide
                alternative representation of an objects shape while ensuring that consumers will know which of the available
                representation is the best.  (Note that not all consumers will implement all shape variations, hence the need
                for the allowing multiple shape objects.)
               
                Since the level attribute is optional, it is necesary for precedence rules to exist to ensure all consumers
                process the shape definition the same way.
                  1. The shape definition with the highest value level attribute is considered the most accurate interpretation.
                  2. If all shape definitions specify the same level, the order from least to most accurate interpretation
                     is presumed to be ellipse, polyline, dxf.
                  3. A shape that specifies the level attribute has precedence over any that do not specify it.
                  4. If the level attribute is absent from all shape definitions, the order from least to most accurate
                     interpretation is presumed to be ellipse, polyline, dxf.
               
</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
         
<xs:attribute name="extrude" type="xs:nonNegativeInteger" use="optional">
           
<xs:annotation>
             
<xs:documentation>A "Height" of the ellipse used to make the flat object encompas a volume.</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
     
<xs:element name="polyline" minOccurs="0">
       
<xs:annotation>
         
<xs:documentation>The poly line provides a mechanism to express arbitrarily complex two-dimenstional shapes.  This is used for representing oddly shaped objects such as exclusion zones, etc.  Though generally closed, it is not necessarily a closed line, thus allowing polyline to represent objects such as phasing lines, etc.</xs:documentation>
       
</xs:annotation>
       
<xs:complexType>
         
<xs:sequence>
           
<xs:element name="vertex" minOccurs="2" maxOccurs="unbounded">
             
<xs:complexType>
               
<xs:attribute name="lat" use="required">
                 
<xs:annotation>
                   
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.</xs:documentation>
                 
</xs:annotation>
                 
<xs:simpleType>
                   
<xs:restriction base="xs:decimal">
                     
<xs:minInclusive value="-90"/>
                     
<xs:maxInclusive value="90"/>
                   
</xs:restriction>
                 
</xs:simpleType>
               
</xs:attribute>
               
<xs:attribute name="lon" use="required">
                 
<xs:annotation>
                   
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.</xs:documentation>
                 
</xs:annotation>
                 
<xs:simpleType>
                   
<xs:restriction base="xs:decimal">
                     
<xs:minInclusive value="-180"/>
                     
<xs:maxInclusive value="180"/>
                   
</xs:restriction>
                 
</xs:simpleType>
               
</xs:attribute>
               
<xs:attribute name="hae" type="xs:decimal" use="optional">
                 
<xs:annotation>
                   
<xs:documentation>Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.</xs:documentation>
                 
</xs:annotation>
               
</xs:attribute>
             
</xs:complexType>
           
</xs:element>
         
</xs:sequence>
         
<xs:attribute name="level" type="xs:integer">
           
<xs:annotation>
             
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
               
                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
               
</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
         
<xs:attribute name="closed" type="xs:boolean" default="true">
           
<xs:annotation>
             
<xs:documentation>True if the list of verticies should be considered a closed polygon (an implicit line will be added from vertex N to vertex 0).</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
     
<xs:element name="dxf" minOccurs="0">
       
<xs:annotation>
         
<xs:documentation>This is a hook for an arbitrary 3D DXF description of a volume of space.</xs:documentation>
       
</xs:annotation>
       
<xs:complexType>
         
<xs:sequence>
           
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         
</xs:sequence>
         
<xs:attribute name="level" type="xs:integer">
           
<xs:annotation>
             
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
                                                                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
                                                               
</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
   
</xs:sequence>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Can be used to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute shape/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Can be used to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Can be used to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element shape/ellipse
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p13.png
properties
minOcc 0
maxOcc 1
content complex
attributes
Name  Type  Use  Default  Fixed  Annotation
major  nonNegativeDecimal  required      
documentation
Ellipse major axis (meters)
minor  nonNegativeDecimal  required      
documentation
Ellipse minor axis (meters)
angle  xs:decimal  required      
documentation
Orientation of major axis with respect to true north.
level  xs:integer  optional      
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas. 
                For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher
                level value will be the "more desirable" representation of the object.  This allows producers to provide
                alternative representation of an objects shape while ensuring that consumers will know which of the available
                representation is the best.  (Note that not all consumers will implement all shape variations, hence the need
                for the allowing multiple shape objects.)
               
                Since the level attribute is optional, it is necesary for precedence rules to exist to ensure all consumers
                process the shape definition the same way.
                  1. The shape definition with the highest value level attribute is considered the most accurate interpretation.
                  2. If all shape definitions specify the same level, the order from least to most accurate interpretation
                     is presumed to be ellipse, polyline, dxf.
                  3. A shape that specifies the level attribute has precedence over any that do not specify it.
                  4. If the level attribute is absent from all shape definitions, the order from least to most accurate
                     interpretation is presumed to be ellipse, polyline, dxf.
               
extrude  xs:nonNegativeInteger  optional      
documentation
A "Height" of the ellipse used to make the flat object encompas a volume.
annotation
documentation
The "ellipse" is a common shape abstraction used by many geomanipulation applications; it is supported natively.
source <xs:element name="ellipse" minOccurs="0">
 
<xs:annotation>
   
<xs:documentation>The "ellipse" is a common shape abstraction used by many geomanipulation applications; it is supported natively.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="major" type="nonNegativeDecimal" use="required">
     
<xs:annotation>
       
<xs:documentation>Ellipse major axis (meters)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="minor" type="nonNegativeDecimal" use="required">
     
<xs:annotation>
       
<xs:documentation>Ellipse minor axis (meters)</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="angle" type="xs:decimal" use="required">
     
<xs:annotation>
       
<xs:documentation>Orientation of major axis with respect to true north. </xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="level" type="xs:integer" use="optional">
     
<xs:annotation>
       
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas. 
                For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher
                level value will be the "more desirable" representation of the object.  This allows producers to provide
                alternative representation of an objects shape while ensuring that consumers will know which of the available
                representation is the best.  (Note that not all consumers will implement all shape variations, hence the need
                for the allowing multiple shape objects.)
               
                Since the level attribute is optional, it is necesary for precedence rules to exist to ensure all consumers
                process the shape definition the same way.
                  1. The shape definition with the highest value level attribute is considered the most accurate interpretation.
                  2. If all shape definitions specify the same level, the order from least to most accurate interpretation
                     is presumed to be ellipse, polyline, dxf.
                  3. A shape that specifies the level attribute has precedence over any that do not specify it.
                  4. If the level attribute is absent from all shape definitions, the order from least to most accurate
                     interpretation is presumed to be ellipse, polyline, dxf.
               
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="extrude" type="xs:nonNegativeInteger" use="optional">
     
<xs:annotation>
       
<xs:documentation>A "Height" of the ellipse used to make the flat object encompas a volume.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute shape/ellipse/@major
type nonNegativeDecimal
properties
use required
facets
Kind Value Annotation
minInclusive 0
annotation
documentation
Ellipse major axis (meters)
source <xs:attribute name="major" type="nonNegativeDecimal" use="required">
 
<xs:annotation>
   
<xs:documentation>Ellipse major axis (meters)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute shape/ellipse/@minor
type nonNegativeDecimal
properties
use required
facets
Kind Value Annotation
minInclusive 0
annotation
documentation
Ellipse minor axis (meters)
source <xs:attribute name="minor" type="nonNegativeDecimal" use="required">
 
<xs:annotation>
   
<xs:documentation>Ellipse minor axis (meters)</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute shape/ellipse/@angle
type xs:decimal
properties
use required
annotation
documentation
Orientation of major axis with respect to true north.
source <xs:attribute name="angle" type="xs:decimal" use="required">
 
<xs:annotation>
   
<xs:documentation>Orientation of major axis with respect to true north. </xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute shape/ellipse/@level
type xs:integer
properties
use optional
annotation
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas. 
                For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher
                level value will be the "more desirable" representation of the object.  This allows producers to provide
                alternative representation of an objects shape while ensuring that consumers will know which of the available
                representation is the best.  (Note that not all consumers will implement all shape variations, hence the need
                for the allowing multiple shape objects.)
               
                Since the level attribute is optional, it is necesary for precedence rules to exist to ensure all consumers
                process the shape definition the same way.
                  1. The shape definition with the highest value level attribute is considered the most accurate interpretation.
                  2. If all shape definitions specify the same level, the order from least to most accurate interpretation
                     is presumed to be ellipse, polyline, dxf.
                  3. A shape that specifies the level attribute has precedence over any that do not specify it.
                  4. If the level attribute is absent from all shape definitions, the order from least to most accurate
                     interpretation is presumed to be ellipse, polyline, dxf.
               
source <xs:attribute name="level" type="xs:integer" use="optional">
 
<xs:annotation>
   
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas. 
                For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher
                level value will be the "more desirable" representation of the object.  This allows producers to provide
                alternative representation of an objects shape while ensuring that consumers will know which of the available
                representation is the best.  (Note that not all consumers will implement all shape variations, hence the need
                for the allowing multiple shape objects.)
               
                Since the level attribute is optional, it is necesary for precedence rules to exist to ensure all consumers
                process the shape definition the same way.
                  1. The shape definition with the highest value level attribute is considered the most accurate interpretation.
                  2. If all shape definitions specify the same level, the order from least to most accurate interpretation
                     is presumed to be ellipse, polyline, dxf.
                  3. A shape that specifies the level attribute has precedence over any that do not specify it.
                  4. If the level attribute is absent from all shape definitions, the order from least to most accurate
                     interpretation is presumed to be ellipse, polyline, dxf.
               
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute shape/ellipse/@extrude
type xs:nonNegativeInteger
properties
use optional
annotation
documentation
A "Height" of the ellipse used to make the flat object encompas a volume.
source <xs:attribute name="extrude" type="xs:nonNegativeInteger" use="optional">
 
<xs:annotation>
   
<xs:documentation>A "Height" of the ellipse used to make the flat object encompas a volume.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element shape/polyline
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p14.png
properties
minOcc 0
maxOcc 1
content complex
children vertex
attributes
Name  Type  Use  Default  Fixed  Annotation
level  xs:integer        
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
               
                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
               
closed  xs:boolean    true    
documentation
True if the list of verticies should be considered a closed polygon (an implicit line will be added from vertex N to vertex 0).
annotation
documentation
The poly line provides a mechanism to express arbitrarily complex two-dimenstional shapes.  This is used for representing oddly shaped objects such as exclusion zones, etc.  Though generally closed, it is not necessarily a closed line, thus allowing polyline to represent objects such as phasing lines, etc.
source <xs:element name="polyline" minOccurs="0">
 
<xs:annotation>
   
<xs:documentation>The poly line provides a mechanism to express arbitrarily complex two-dimenstional shapes.  This is used for representing oddly shaped objects such as exclusion zones, etc.  Though generally closed, it is not necessarily a closed line, thus allowing polyline to represent objects such as phasing lines, etc.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:element name="vertex" minOccurs="2" maxOccurs="unbounded">
       
<xs:complexType>
         
<xs:attribute name="lat" use="required">
           
<xs:annotation>
             
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minInclusive value="-90"/>
               
<xs:maxInclusive value="90"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="lon" use="required">
           
<xs:annotation>
             
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minInclusive value="-180"/>
               
<xs:maxInclusive value="180"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="hae" type="xs:decimal" use="optional">
           
<xs:annotation>
             
<xs:documentation>Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.</xs:documentation>
           
</xs:annotation>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
   
</xs:sequence>
   
<xs:attribute name="level" type="xs:integer">
     
<xs:annotation>
       
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
               
                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
               
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="closed" type="xs:boolean" default="true">
     
<xs:annotation>
       
<xs:documentation>True if the list of verticies should be considered a closed polygon (an implicit line will be added from vertex N to vertex 0).</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute shape/polyline/@level
type xs:integer
annotation
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
               
                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
               
source <xs:attribute name="level" type="xs:integer">
 
<xs:annotation>
   
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
               
                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
               
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute shape/polyline/@closed
type xs:boolean
properties
default true
annotation
documentation
True if the list of verticies should be considered a closed polygon (an implicit line will be added from vertex N to vertex 0).
source <xs:attribute name="closed" type="xs:boolean" default="true">
 
<xs:annotation>
   
<xs:documentation>True if the list of verticies should be considered a closed polygon (an implicit line will be added from vertex N to vertex 0).</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element shape/polyline/vertex
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p15.png
properties
minOcc 2
maxOcc unbounded
content complex
attributes
Name  Type  Use  Default  Fixed  Annotation
lat  derived by: xs:decimal  required      
documentation
Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.
lon  derived by: xs:decimal  required      
documentation
Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.
hae  xs:decimal  optional      
documentation
Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.
source <xs:element name="vertex" minOccurs="2" maxOccurs="unbounded">
 
<xs:complexType>
   
<xs:attribute name="lat" use="required">
     
<xs:annotation>
       
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-90"/>
         
<xs:maxInclusive value="90"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="lon" use="required">
     
<xs:annotation>
       
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-180"/>
         
<xs:maxInclusive value="180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="hae" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute shape/polyline/vertex/@lat
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive -90
maxInclusive 90
annotation
documentation
Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.
source <xs:attribute name="lat" use="required">
 
<xs:annotation>
   
<xs:documentation>Latitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. -33.350000). Range -90 -> +90. Positive values denote north.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-90"/>
     
<xs:maxInclusive value="90"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute shape/polyline/vertex/@lon
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive -180
maxInclusive 180
annotation
documentation
Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.
source <xs:attribute name="lon" use="required">
 
<xs:annotation>
   
<xs:documentation>Longitude based on WGS-84 ellipsoid in signed degree-decimal format (e.g. 44.383333). Range -180 -> +180. Positive values denote east.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-180"/>
     
<xs:maxInclusive value="180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute shape/polyline/vertex/@hae
type xs:decimal
properties
use optional
annotation
documentation
Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.
source <xs:attribute name="hae" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Height Above Ellipsoid (HAE) in Meters.  If absent, the value of the point/@hae in the CoT event base schema is used.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element shape/dxf
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p16.png
properties
minOcc 0
maxOcc 1
content complex
attributes
Name  Type  Use  Default  Fixed  Annotation
level  xs:integer        
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
                                                                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
                                                               
annotation
documentation
This is a hook for an arbitrary 3D DXF description of a volume of space.
source <xs:element name="dxf" minOccurs="0">
 
<xs:annotation>
   
<xs:documentation>This is a hook for an arbitrary 3D DXF description of a volume of space.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="level" type="xs:integer">
     
<xs:annotation>
       
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
                                                                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
                                                               
</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute shape/dxf/@level
type xs:integer
annotation
documentation
"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
                                                                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
                                                               
source <xs:attribute name="level" type="xs:integer">
 
<xs:annotation>
   
<xs:documentation>"level" is used to indicate the preferred ordering of multiple shape sub-schemas.  For instance, if a polyline and ellipse are both present on the shape attribute, the one with the higher level value will be the "more desirable" representation of the object.  This allows producers to provide alternative representation of an objects shape while ensuring that consumers will know which of the available representation is the best.  (Note that not all consumers will implement all shape variations, hence the need for the allowing multiple shape objects.)
                                                                See the documentation for shape/ellipse/@level for remarks on determining the precedence order when level values are equal or are missing.
                                                               
</xs:documentation>
 
</xs:annotation>
</xs:attribute>

simpleType nonNegativeDecimal
type restriction of xs:decimal
properties
base xs:decimal
used by
attributes shape/ellipse/@major shape/ellipse/@minor
facets
Kind Value Annotation
minInclusive 0
source <xs:simpleType name="nonNegativeDecimal">
 
<xs:restriction base="xs:decimal">
   
<xs:minInclusive value="0"/>
 
</xs:restriction>
 
<!-- Defined as global type for DoD XML Gallery manifest reference than any other reason -->
</xs:simpleType>

element spatial
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p17.png
properties
content complex
children attitude spin
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
version  xs:decimal  optional      
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
annotation
documentation
This is a Cursor On Target sub-schema for spatial information of physical entity.  It is intended to appear in the detail section of the Cursor On Target schema. It has elements to represent attitude and associated first derivatives (spin). The intention behind the spatial element is to convey the attitude of a body moving through space with respect to its "nominal" flight attitude.
source <xs:element name="spatial">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target sub-schema for spatial information of physical entity.  It is intended to appear in the detail section of the Cursor On Target schema. It has elements to represent attitude and associated first derivatives (spin). The intention behind the spatial element is to convey the attitude of a body moving through space with respect to its "nominal" flight attitude.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:element name="attitude">
       
<xs:annotation>
         
<xs:documentation>Attitude  represents the attitude of the entity described by the Cursor On Target base schema.</xs:documentation>
       
</xs:annotation>
       
<xs:complexType>
         
<xs:sequence>
           
<xs:any minOccurs="0" maxOccurs="unbounded"/>
         
</xs:sequence>
         
<xs:attribute name="roll" use="required">
           
<xs:annotation>
             
<xs:documentation>Roll of entity in degrees. Positive indicates listing to the right.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="-180"/>
               
<xs:maxInclusive value="180"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="pitch" use="required">
           
<xs:annotation>
             
<xs:documentation>Pitch of entity in degrees. Positive indicates nose point up.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:maxInclusive value="180"/>
               
<xs:minExclusive value="-180"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="yaw" use="optional">
           
<xs:annotation>
             
<xs:documentation>Yaw of entity in degrees. Positive indicates turned to the right.

                  Yaw is defined here as is the difference between the craft's
                  pointing direction and it's movement direction (its heading and
                  coruse) (heading - course).  Thinking of this in terms of
                  "oversteer" and "understeer" in a car provides an example. 
                  If your car is traveling normally, going in the direction
                  it's pointed, you have zero yaw.  If you're skidding sideways,
                  you'd then have a "yaw" of 90 degrees, and if that skid is to
                  the right (the passenger side is going to hit first) then your
                  "yaw" is -90 degrees (since you're car is pointed 90 degrees
                  to the left of the direction you're moving.)
</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:maxInclusive value="180"/>
               
<xs:minExclusive value="-180"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="eRoll" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="ePitch" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="eYaw" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
     
<xs:element name="spin">
       
<xs:annotation>
         
<xs:documentation>Spin represents the first derivative of attributes found in attitude.</xs:documentation>
       
</xs:annotation>
       
<xs:complexType>
         
<xs:sequence>
           
<xs:any minOccurs="0" maxOccurs="unbounded"/>
         
</xs:sequence>
         
<xs:attribute name="roll" use="required" form="qualified">
           
<xs:annotation>
             
<xs:documentation>Degrees per second with positive indicating to the pilots right</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal"/>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="pitch" use="required">
           
<xs:annotation>
             
<xs:documentation>Degrees per second with positive indicating nose up.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal"/>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="yaw" use="optional">
           
<xs:annotation>
             
<xs:documentation>Degrees per second with positive indicating right.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal"/>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="eRoll" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="ePitch" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
         
<xs:attribute name="eYaw" use="optional">
           
<xs:annotation>
             
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
           
</xs:annotation>
           
<xs:simpleType>
             
<xs:restriction base="xs:decimal">
               
<xs:minExclusive value="0"/>
             
</xs:restriction>
           
</xs:simpleType>
         
</xs:attribute>
       
</xs:complexType>
     
</xs:element>
   
</xs:sequence>
   
<xs:attribute name="version" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute spatial/@version
type xs:decimal
properties
use optional
annotation
documentation
Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.
source <xs:attribute name="version" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>Version tag for this sub schema.  Neccessary to ensure upward compatibility with future revisions.</xs:documentation>
 
</xs:annotation>
</xs:attribute>

element spatial/attitude
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p18.png
properties
content complex
attributes
Name  Type  Use  Default  Fixed  Annotation
roll  derived by: xs:decimal  required      
documentation
Roll of entity in degrees. Positive indicates listing to the right.
pitch  derived by: xs:decimal  required      
documentation
Pitch of entity in degrees. Positive indicates nose point up.
yaw  derived by: xs:decimal  optional      
documentation
Yaw of entity in degrees. Positive indicates turned to the right.

                  Yaw is defined here as is the difference between the craft's
                  pointing direction and it's movement direction (its heading and
                  coruse) (heading - course).  Thinking of this in terms of
                  "oversteer" and "understeer" in a car provides an example. 
                  If your car is traveling normally, going in the direction
                  it's pointed, you have zero yaw.  If you're skidding sideways,
                  you'd then have a "yaw" of 90 degrees, and if that skid is to
                  the right (the passenger side is going to hit first) then your
                  "yaw" is -90 degrees (since you're car is pointed 90 degrees
                  to the left of the direction you're moving.)
eRoll  derived by: xs:decimal  optional      
documentation
1-sigma error of roll with respect to a zero mean normal Gaussian distribution.
ePitch  derived by: xs:decimal  optional      
documentation
1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.
eYaw  derived by: xs:decimal  optional      
documentation
1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.
annotation
documentation
Attitude  represents the attitude of the entity described by the Cursor On Target base schema.
source <xs:element name="attitude">
 
<xs:annotation>
   
<xs:documentation>Attitude  represents the attitude of the entity described by the Cursor On Target base schema.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="roll" use="required">
     
<xs:annotation>
       
<xs:documentation>Roll of entity in degrees. Positive indicates listing to the right.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="-180"/>
         
<xs:maxInclusive value="180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="pitch" use="required">
     
<xs:annotation>
       
<xs:documentation>Pitch of entity in degrees. Positive indicates nose point up.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:maxInclusive value="180"/>
         
<xs:minExclusive value="-180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="yaw" use="optional">
     
<xs:annotation>
       
<xs:documentation>Yaw of entity in degrees. Positive indicates turned to the right.

                  Yaw is defined here as is the difference between the craft's
                  pointing direction and it's movement direction (its heading and
                  coruse) (heading - course).  Thinking of this in terms of
                  "oversteer" and "understeer" in a car provides an example. 
                  If your car is traveling normally, going in the direction
                  it's pointed, you have zero yaw.  If you're skidding sideways,
                  you'd then have a "yaw" of 90 degrees, and if that skid is to
                  the right (the passenger side is going to hit first) then your
                  "yaw" is -90 degrees (since you're car is pointed 90 degrees
                  to the left of the direction you're moving.)
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:maxInclusive value="180"/>
         
<xs:minExclusive value="-180"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="eRoll" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="ePitch" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="eYaw" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute spatial/attitude/@roll
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
maxInclusive 180
minExclusive -180
annotation
documentation
Roll of entity in degrees. Positive indicates listing to the right.
source <xs:attribute name="roll" use="required">
 
<xs:annotation>
   
<xs:documentation>Roll of entity in degrees. Positive indicates listing to the right.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="-180"/>
     
<xs:maxInclusive value="180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/attitude/@pitch
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
maxInclusive 180
minExclusive -180
annotation
documentation
Pitch of entity in degrees. Positive indicates nose point up.
source <xs:attribute name="pitch" use="required">
 
<xs:annotation>
   
<xs:documentation>Pitch of entity in degrees. Positive indicates nose point up.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:maxInclusive value="180"/>
     
<xs:minExclusive value="-180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/attitude/@yaw
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
maxInclusive 180
minExclusive -180
annotation
documentation
Yaw of entity in degrees. Positive indicates turned to the right.

                  Yaw is defined here as is the difference between the craft's
                  pointing direction and it's movement direction (its heading and
                  coruse) (heading - course).  Thinking of this in terms of
                  "oversteer" and "understeer" in a car provides an example. 
                  If your car is traveling normally, going in the direction
                  it's pointed, you have zero yaw.  If you're skidding sideways,
                  you'd then have a "yaw" of 90 degrees, and if that skid is to
                  the right (the passenger side is going to hit first) then your
                  "yaw" is -90 degrees (since you're car is pointed 90 degrees
                  to the left of the direction you're moving.)
source <xs:attribute name="yaw" use="optional">
 
<xs:annotation>
   
<xs:documentation>Yaw of entity in degrees. Positive indicates turned to the right.

                  Yaw is defined here as is the difference between the craft's
                  pointing direction and it's movement direction (its heading and
                  coruse) (heading - course).  Thinking of this in terms of
                  "oversteer" and "understeer" in a car provides an example. 
                  If your car is traveling normally, going in the direction
                  it's pointed, you have zero yaw.  If you're skidding sideways,
                  you'd then have a "yaw" of 90 degrees, and if that skid is to
                  the right (the passenger side is going to hit first) then your
                  "yaw" is -90 degrees (since you're car is pointed 90 degrees
                  to the left of the direction you're moving.)
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:maxInclusive value="180"/>
     
<xs:minExclusive value="-180"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/attitude/@eRoll
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of roll with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="eRoll" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/attitude/@ePitch
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="ePitch" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/attitude/@eYaw
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="eYaw" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

element spatial/spin
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p19.png
properties
content complex
attributes
Name  Type  Use  Default  Fixed  Annotation
roll  derived by: xs:decimal  required      
documentation
Degrees per second with positive indicating to the pilots right
pitch  derived by: xs:decimal  required      
documentation
Degrees per second with positive indicating nose up.
yaw  derived by: xs:decimal  optional      
documentation
Degrees per second with positive indicating right.
eRoll  derived by: xs:decimal  optional      
documentation
1-sigma error of roll with respect to a zero mean normal Gaussian distribution.
ePitch  derived by: xs:decimal  optional      
documentation
1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.
eYaw  derived by: xs:decimal  optional      
documentation
1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.
annotation
documentation
Spin represents the first derivative of attributes found in attitude.
source <xs:element name="spin">
 
<xs:annotation>
   
<xs:documentation>Spin represents the first derivative of attributes found in attitude.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="roll" use="required" form="qualified">
     
<xs:annotation>
       
<xs:documentation>Degrees per second with positive indicating to the pilots right</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal"/>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="pitch" use="required">
     
<xs:annotation>
       
<xs:documentation>Degrees per second with positive indicating nose up.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal"/>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="yaw" use="optional">
     
<xs:annotation>
       
<xs:documentation>Degrees per second with positive indicating right.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal"/>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="eRoll" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="ePitch" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="eYaw" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minExclusive value="0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
 
</xs:complexType>
</xs:element>

attribute spatial/spin/@roll
type restriction of xs:decimal
properties
use required
form qualified
annotation
documentation
Degrees per second with positive indicating to the pilots right
source <xs:attribute name="roll" use="required" form="qualified">
 
<xs:annotation>
   
<xs:documentation>Degrees per second with positive indicating to the pilots right</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal"/>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/spin/@pitch
type restriction of xs:decimal
properties
use required
annotation
documentation
Degrees per second with positive indicating nose up.
source <xs:attribute name="pitch" use="required">
 
<xs:annotation>
   
<xs:documentation>Degrees per second with positive indicating nose up.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal"/>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/spin/@yaw
type restriction of xs:decimal
properties
use optional
annotation
documentation
Degrees per second with positive indicating right.
source <xs:attribute name="yaw" use="optional">
 
<xs:annotation>
   
<xs:documentation>Degrees per second with positive indicating right.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal"/>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/spin/@eRoll
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of roll with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="eRoll" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of roll with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/spin/@ePitch
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="ePitch" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of pitch with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute spatial/spin/@eYaw
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minExclusive 0
annotation
documentation
1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.
source <xs:attribute name="eYaw" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error of yaw with respect to a zero mean normal Gaussian distribution.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minExclusive value="0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

element track
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p20.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
course  derived by: xs:decimal  required      
documentation
Direction of motion with respect to true north. Measured in degrees.
speed  derived by: xs:decimal  required      
documentation
Magnitude of motion measured in meters per second
         
          The “speed” attribute in the track entity represents the magnitude of
          the object’s velocity in three space.  That is, an object is falling
          vertically toward the Earth at a velocity of 100m/s it should have a
          reported “speed” of 100m/s even though it’s effective “ground speed” is
          zero.  Furthermore, the reported speed reflect that objects changing
          position in three space, not it’s motion through the medium, hence, an
          object flying at 100m/s directly into a 100m/s head wind would have a
          reported “speed” of zero despite the fact that it’s indicated airspeed
          in 100m/s. 

          We observe that many systems (incorrectly) report only the horizontal
          components of their velocity.  While not strictly correct, the resultant
          velocity errors tend to be small for terrestrial and surface systems. 
          While airborne systems have the potential for much larger vertical
          components, vertical velocities generally remain relatively small for
          lift-based air vehicles in typical flight profiles.  Aggressively
          maneuvering aircraft and ballistic vehicles may have dominant vertical
          velocities and should accurately report the 3D vector.  We expect that
          the systems that (incorrectly) report only their horizontal velocity
          will not populate the “slope” attribute the of the track entity.
         
slope  derived by: xs:decimal  optional      
documentation
Vertical component of motion vector. Measured in degrees. Negative indicates downward motion.
eCourse  xs:decimal  optional      
documentation
1-sigma error on a Gaussian distribution associated with the course attribute
eSpeed  xs:decimal  optional      
documentation
1-sigma error on a Gaussian distribution associated with the speed attribute
eSlope  xs:decimal  optional      
documentation
1-sigma error on a Gaussian distribution associated with the slope attribute
version  xs:decimal  optional      
annotation
documentation
This is a Cursor On Target detail sub-schema for track information.  The root element and associated attributes of this schema are intended to appear in the detail element of the Cursor On Target schema.
source <xs:element name="track">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target detail sub-schema for track information.  The root element and associated attributes of this schema are intended to appear in the detail element of the Cursor On Target schema.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="course" use="required">
     
<xs:annotation>
       
<xs:documentation>Direction of motion with respect to true north. Measured in degrees.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0"/>
         
<xs:maxExclusive value="360"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="speed" use="required">
     
<xs:annotation>
       
<xs:documentation>Magnitude of motion measured in meters per second
         
          The “speed” attribute in the track entity represents the magnitude of
          the object’s velocity in three space.  That is, an object is falling
          vertically toward the Earth at a velocity of 100m/s it should have a
          reported “speed” of 100m/s even though it’s effective “ground speed” is
          zero.  Furthermore, the reported speed reflect that objects changing
          position in three space, not it’s motion through the medium, hence, an
          object flying at 100m/s directly into a 100m/s head wind would have a
          reported “speed” of zero despite the fact that it’s indicated airspeed
          in 100m/s. 

          We observe that many systems (incorrectly) report only the horizontal
          components of their velocity.  While not strictly correct, the resultant
          velocity errors tend to be small for terrestrial and surface systems. 
          While airborne systems have the potential for much larger vertical
          components, vertical velocities generally remain relatively small for
          lift-based air vehicles in typical flight profiles.  Aggressively
          maneuvering aircraft and ballistic vehicles may have dominant vertical
          velocities and should accurately report the 3D vector.  We expect that
          the systems that (incorrectly) report only their horizontal velocity
          will not populate the “slope” attribute the of the track entity.
         
</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="0.0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="slope" use="optional">
     
<xs:annotation>
       
<xs:documentation>Vertical component of motion vector. Measured in degrees. Negative indicates downward motion.</xs:documentation>
     
</xs:annotation>
     
<xs:simpleType>
       
<xs:restriction base="xs:decimal">
         
<xs:minInclusive value="-90.0"/>
         
<xs:maxInclusive value="90.0"/>
       
</xs:restriction>
     
</xs:simpleType>
   
</xs:attribute>
   
<xs:attribute name="eCourse" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error on a Gaussian distribution associated with the course attribute</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="eSpeed" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error on a Gaussian distribution associated with the speed attribute</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="eSlope" type="xs:decimal" use="optional">
     
<xs:annotation>
       
<xs:documentation>1-sigma error on a Gaussian distribution associated with the slope attribute</xs:documentation>
     
</xs:annotation>
   
</xs:attribute>
   
<xs:attribute name="version" type="xs:decimal" use="optional"/>
 
</xs:complexType>
</xs:element>

attribute track/@course
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive 0
maxExclusive 360
annotation
documentation
Direction of motion with respect to true north. Measured in degrees.
source <xs:attribute name="course" use="required">
 
<xs:annotation>
   
<xs:documentation>Direction of motion with respect to true north. Measured in degrees.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0"/>
     
<xs:maxExclusive value="360"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute track/@speed
type restriction of xs:decimal
properties
use required
facets
Kind Value Annotation
minInclusive 0.0
annotation
documentation
Magnitude of motion measured in meters per second
         
          The “speed” attribute in the track entity represents the magnitude of
          the object’s velocity in three space.  That is, an object is falling
          vertically toward the Earth at a velocity of 100m/s it should have a
          reported “speed” of 100m/s even though it’s effective “ground speed” is
          zero.  Furthermore, the reported speed reflect that objects changing
          position in three space, not it’s motion through the medium, hence, an
          object flying at 100m/s directly into a 100m/s head wind would have a
          reported “speed” of zero despite the fact that it’s indicated airspeed
          in 100m/s. 

          We observe that many systems (incorrectly) report only the horizontal
          components of their velocity.  While not strictly correct, the resultant
          velocity errors tend to be small for terrestrial and surface systems. 
          While airborne systems have the potential for much larger vertical
          components, vertical velocities generally remain relatively small for
          lift-based air vehicles in typical flight profiles.  Aggressively
          maneuvering aircraft and ballistic vehicles may have dominant vertical
          velocities and should accurately report the 3D vector.  We expect that
          the systems that (incorrectly) report only their horizontal velocity
          will not populate the “slope” attribute the of the track entity.
         
source <xs:attribute name="speed" use="required">
 
<xs:annotation>
   
<xs:documentation>Magnitude of motion measured in meters per second
         
          The “speed” attribute in the track entity represents the magnitude of
          the object’s velocity in three space.  That is, an object is falling
          vertically toward the Earth at a velocity of 100m/s it should have a
          reported “speed” of 100m/s even though it’s effective “ground speed” is
          zero.  Furthermore, the reported speed reflect that objects changing
          position in three space, not it’s motion through the medium, hence, an
          object flying at 100m/s directly into a 100m/s head wind would have a
          reported “speed” of zero despite the fact that it’s indicated airspeed
          in 100m/s. 

          We observe that many systems (incorrectly) report only the horizontal
          components of their velocity.  While not strictly correct, the resultant
          velocity errors tend to be small for terrestrial and surface systems. 
          While airborne systems have the potential for much larger vertical
          components, vertical velocities generally remain relatively small for
          lift-based air vehicles in typical flight profiles.  Aggressively
          maneuvering aircraft and ballistic vehicles may have dominant vertical
          velocities and should accurately report the 3D vector.  We expect that
          the systems that (incorrectly) report only their horizontal velocity
          will not populate the “slope” attribute the of the track entity.
         
</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="0.0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute track/@slope
type restriction of xs:decimal
properties
use optional
facets
Kind Value Annotation
minInclusive -90.0
maxInclusive 90.0
annotation
documentation
Vertical component of motion vector. Measured in degrees. Negative indicates downward motion.
source <xs:attribute name="slope" use="optional">
 
<xs:annotation>
   
<xs:documentation>Vertical component of motion vector. Measured in degrees. Negative indicates downward motion.</xs:documentation>
 
</xs:annotation>
 
<xs:simpleType>
   
<xs:restriction base="xs:decimal">
     
<xs:minInclusive value="-90.0"/>
     
<xs:maxInclusive value="90.0"/>
   
</xs:restriction>
 
</xs:simpleType>
</xs:attribute>

attribute track/@eCourse
type xs:decimal
properties
use optional
annotation
documentation
1-sigma error on a Gaussian distribution associated with the course attribute
source <xs:attribute name="eCourse" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error on a Gaussian distribution associated with the course attribute</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute track/@eSpeed
type xs:decimal
properties
use optional
annotation
documentation
1-sigma error on a Gaussian distribution associated with the speed attribute
source <xs:attribute name="eSpeed" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error on a Gaussian distribution associated with the speed attribute</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute track/@eSlope
type xs:decimal
properties
use optional
annotation
documentation
1-sigma error on a Gaussian distribution associated with the slope attribute
source <xs:attribute name="eSlope" type="xs:decimal" use="optional">
 
<xs:annotation>
   
<xs:documentation>1-sigma error on a Gaussian distribution associated with the slope attribute</xs:documentation>
 
</xs:annotation>
</xs:attribute>

attribute track/@version
type xs:decimal
properties
use optional
source <xs:attribute name="version" type="xs:decimal" use="optional"/>

element uid
diagram CursorOnTargetCombined_diagrams/CursorOnTargetCombined_p21.png
properties
content complex
used by
element CursorOnTarget
attributes
Name  Type  Use  Default  Fixed  Annotation
version  xs:decimal  optional      
annotation
documentation
This is a Cursor On Target detail sub-schema that holds the unique ID assigned by each system that processed this event.  Most systems (including CoT) have their own method for assigning system-wide unique identifiers for a particular object.  In general, it is not possible for a single UID to be used for all systems.  This 'uid' entity provides a common place where each systems can record its  particular UID for each CoT event.  Like the _flow-tags_ element, each system is responsible for adding its own attribute to this entity.  The name of the attribute should represent the system, and the value of the attribute should be the id that system assigned to this CoT object.
source <xs:element name="uid">
 
<xs:annotation>
   
<xs:documentation>This is a Cursor On Target detail sub-schema that holds the unique ID assigned by each system that processed this event.  Most systems (including CoT) have their own method for assigning system-wide unique identifiers for a particular object.  In general, it is not possible for a single UID to be used for all systems.  This 'uid' entity provides a common place where each systems can record its  particular UID for each CoT event.  Like the _flow-tags_ element, each system is responsible for adding its own attribute to this entity.  The name of the attribute should represent the system, and the value of the attribute should be the id that system assigned to this CoT object.</xs:documentation>
 
</xs:annotation>
 
<xs:complexType>
   
<xs:sequence>
     
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   
</xs:sequence>
   
<xs:attribute name="version" type="xs:decimal" use="optional"/>
   
<xs:anyAttribute processContents="lax">
     
<xs:annotation>
       
<xs:documentation>The system-specific identifier (a.k.a UID, or track number) associated with the entity described by the encapsulating CoT object.</xs:documentation>
     
</xs:annotation>
   
</xs:anyAttribute>
 
</xs:complexType>
</xs:element>

attribute uid/@version
type xs:decimal
properties
use optional
source <xs:attribute name="version" type="xs:decimal" use="optional"/>


XML Schema documentation generated by XMLSpy Schema Editor http://www.altova.com/xmlspy