RE: [emergency] Tactical Situation Object

["David RR Webber \(XML\)" <david@drrw.info>]

Rex,

Courtesy of my MARC train ride this morning - here is my analysis on their schema - attached ZIP.

I've provided a couple of HTML reports in the ZIP that help understand their data model.  Plus I provided comments on specific elements - see text below - and their data model - which overall - IMHO is somewhat "Fisher Price" XML.  I provide an Excel spreadsheet of their dictionary.

Also - I used the renamer tool to fix their short uppercase names into new camel case names that are fully NIEM term reference compliant - and build a dictionary of those new terms.

My suggestion would be to re-use their dictionary components - but construct a new OASIS style EDXL aligned message structure, message metadata, and with a better information model.

Of course I have to admit a vested interest in this - you can potentially use the new CAM v1.8 blueprint system to perform this surgery - create a blueprint outline of the information structure - then insert the components in the appropriate places from the dictionary.

Then I rewrote their existing schema using XSD export - and this actually wrote their XSD back out better than their original (IMHO!) - a scary "first" for CAM - I've not seen it write schema better than humans before!

Overall I see that XML maturity wise the OASIS team here just is way better than CEN!?!?  But we would say that wouldn't we?

 

Thanks, DW

====================

Things that raise eyebrows

Abbreviation of names - several arbitrary - not really saving byte count - e.g. Risk_Assessmnt - and DATIME - DateTime

Handling of address - unformatted 256 byte string - heavily overloaded - sometimes its milestone marker, sometimes address.

Name conflict / EVAC and EVACUATED

RGEO, EGEO - would be better to have parent Event, Resource - then child elements

ENV - bad abbreviation - better ENVIR

LOCTYPE - 0-80 - This is really Location Type and they have the code values in data dictionary. Probably a function of address.

URGENCY - seems slightly odd - better as URGENT boolean, or have values 0 through 5.

SECLASS - really Security Classification - some may have issues with their code system

ACTOR - this concept appears weird - suspect much better data model possible

OBS_DATIME -  really not clear what OBS is!

TRIAGE codes - again think approach as in EDXL-HAVE is much better data model

POSITION - seems like the data model here is clumsy

Can produce a better organized heirarchical model - e.g.

They have

TSO_V20

 - Context

 - Event

 - Resource

 - Mission

alternative

OASIS_TSO

 - MessageMetadata

 - Event

 -- Location

 - Resources

 -- Organization

 -- Services

 -- Weather

 - Mission

 -- Resolutions

 

This will also fix a lot of the naming issues and make a more consistent data model and allow

reuse of common patterns from EDXL, NIEM, LEXS

-------- Original Message --------
Subject: [emergency] Tactical Situation Object
From: Rex Brooks <rexb@starbourne.com>
Date: Tue, April 06, 2010 9:20 am
To: emergency TC lists Oasis <emergency@lists.oasis-open.org>,
emergency-msg@lists.oasis-open.org, EM GIS SC
<emergency-gis@lists.oasis-open.org>,
"emergency-if@lists.oasis-open.org" <emergency-if@lists.oasis-open.org>,
"emergency-rim@lists.oasis-open.org"
<emergency-rim@lists.oasis-open.org>

Hi Everyone,

I tried to send the main presentation on the Tactical Situation Object
(TSO) yesterday, but it was too large for the OASIS Server's limit, so I
am sending out the url for the presentation which I hope you will all
take the time to look at because i think we must take this effort into
account, and use it as best we can.

TSO Org: http://www.tacticalsituationobject.org/
TSO Presentation:
http://www.tacticalsituationobject.org/docs/Shared-Situation-Awareness-the%20TSO-15Dec2008.pdf

Since it specifies aspects of interoperability with CAP and used
EDXL-DE, I believe it may also be adaptable to some of the gaps in our
current set of EDXL specifications.

I will be incorporating it into the NCOIC All Hazards Alert and Warning
(AHAW) Capabilities Pattern, and it will also be the subject of one of
two specific AHAW Technical Patterns.

Cheers,
Rex

--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

CEN-TSO.zug