Machine‐readable tables for

ANSI/NIST‐ITLand associated application profiles

Austin HicklinANSI/NIST‐ITL Workshop 2013January 2013
How is ANSI/NIST‐ITL actually implemented?
Implementing data from field tables

Many of tfield attrican be useasily and unambigu

But many rinterpretaindividual rules inefficierisk of tyrisk of misinterpr
Implementing field codes

Latent

Tables are in different formats, and the text indicates that different fields/information items often refer to different subsets inefficientrisk of typosrisk of misinterpretation
Exceptions

Some fields are exceptionindicated unambiguously high risk of incorrect im
Application profiles (e.g. FBI EBTS, DoD EBTS, IN

ANSI/NIST-ITL is rarely used directly: most of the fields used are defined in the application profile. 

Most of the implementatrequirements derive from transactions, which are naddressed in ANSI/NIST-IT

Table formats and content differ. inefficient risk of typos 

Terminologmost notabhigh risk implement
XML

Field contents, length, legal characters, format often vary between XML and traditional. 

Traditional Max length Example

2.0005 RET Retention Code 1 Y

2.0022 DOB Date of Birth 8 19790815

XML Max length Example

2.0005 RET Retention Code 5 True

2.0022 DOB Date of Birth 10 1979‐08‐15

The information necompliance checkintranslation betweetraditional is defineplaces and is often inefficient risk of typos risk of misinterprisk of diverging 

There is not a 1:1 correspondence between XML elements and traditional fields, often just simple separators, but sometimes complex. 
Summary of issues in implementing ANSI/N

• Errors introduced by typos, and inefficiencies / wasted effort in 

by hand tables that cannot be read by machine

• Inefficiencies and misunderstandings due to different formats a

between ANSI/NIST tables and EBTS, as well as between differeapplication profiles

• Requirements defined only in the text of the specification

• Exceptions and special cases are not clearly indicated

• No efficient way of knowing exactly what changed between two 

a specification

• It is important to make sure that a standard is unambiguous an

straightforward to implement
Recommended solution
Overview

• Immediate need

– Tables for various FBI‐sponsored software (ULW, UFW, FBI compliance check

– Machine‐readable data tables incorporating

• field requirements from AN2011 and FBI EBTS

• transaction requirements from FBI EBTS

• Designed to be applicable to a broad range of use cases

– Compliance– Processing– Creation/editing/viewing– Translation: between application profiles, between traditional and XML– Precise differences between versions of a standard

• Proposed formats are mostly complete

• Requesting working group to finalize formats and review details• NIST has agreed to host the AN2011 tables on its website

• FBI can host the EBTS tables on its website

• Requesting other agencies with application profiles (DoD, Interp

standards agencies) to consider adopting tables in these format
• Expand the existing AN2011 and EBTS tables

• Useful for a variety of tools for a variety of purposes (e.g. creati

displaying, processing, and checking transactions)

• Include both XML and traditional formats

• Explicitly flag fields that are exceptions to general cases

• Master tables are maintained as spreadsheets, but designed for 

conversion to multiple formats to ease implementation (e.g. de

XML, YAML, JSON)

• Format will allow precise detailing of revisions between version

• A common format means that conformance/compliance checke

across multiple application profiles (e.g. FBI EBTS and INT‐I) merchanging tables

Goals
Tables

• ANSI/NIST tables

– Field definition– Lookup codes

• Application profile tables

– (Designed to layer on top of ANSI/NIST tables)– Field definition– Lookup codes– Transaction record and field definitions
FieldDefinition table

• Each entry represents one field,

information item, and/or XMLelement

• Existing attributes

– Record/field number– Mnemonic– Description– Condition code (expanded)– Data/character type (expanded)

– Min/Max length– Min/Max # of occurrences

• New attributes

– explicit listing of specia

– XML element, full Xpat– XML exception (define

between traditional an

– CodeTable reference– Value range– Regular expression– Inter‐field dependenci

• presence• values

– Summary

• App profile only

– AN field revised in app 
LookupCode table

• Explicitly lists every field code with definition• Can be used in combination with the value range in the FieldDe

table to accommodate varying ranges of frequently‐used tables 

finger/palm/plantar position)
Transaction tables

• TOTrecords • TOTfields

– Defines record set requirements – Defines field requirem

– Inter‐field dependenci

• presence• occurrences• values
Takeaway

• We are developing machine‐readable data tables

• Currently covering AN2011 and EBTS94

• Immediate need is for ULW, UFW, and the EBTS compliance che

– but designed to apply to as many use cases as possible

• When complete

– NIST has agreed to host the AN2011 tables on its website

– FBI can host the EBTS tables on its website

• Requests:

– Requesting working group to finalize formats and review details– Requesting other agencies with application profiles (DoD, Interpol, 

standards agencies) to consider adopting tables in these formats