ANSI/NIST XML ANSI/NIST XML

Post

-March 08 Draf

March 08 Draf

Meeting Meeting

Elaine Newton Elaine Newton

NIST
Scope of A/N XML Part 

Scope of A/N XML Part 

 Discussed at Workshops in April and De

Discussed at Workshops in April and De

2005 and September 2007 2005 and September 2007

 Agreed to making Part 2 an XML version of 

Agreed to making Part 2 an XML version of 

 Part 1 is not open for amendments Part 1 is not open for amendments

 Agreed to proposed structure by XML Wor

Agreed to proposed structure by XML Wor

Chair (Gerry Coleman), utilizing NIEM Chair (Gerry Coleman), utilizing NIEM ansi

namespace proposed by NIEM A/N Liaison namespace proposed by NIEM A/N Liaiso(Patrice (Patrice Yuh)
 Standard created originally for law enforc

Expanded Use of NIST Stan

Expanded Use of NIST Stan

Standard created originally for law enforcpurposes and used chiefly for law enforce

purposes and used chiefly for law enforc

 A/N-I 1-2007 reflected expanding role o

2007 reflected expanding role o

NIST standard to exchange biometric da

NIST standard to exchange biometric da

 Today, comments from the Department 

Today, comments from the Department 

Homeland Security (DHS) and the Terro

Homeland Security (DHS) and the Terro

Screening Center (TSC) request changes 

Screening Center (TSC) request changes 

their needs to exchange biometric data their needs to exchange biometric data
Summary of DHS comments f

DHS

-OCIO 3

Summary of DHS comments f

DHS

-OCIO 3 



“The paradigm created here is that the Part 1 identifies 

The paradigm created here is that the Part 1 identifies 

logical requirements and the Part 2 is simply the XML logical requirements and the Part 2 is simply the XML-that exact same set of requirements. that exact same set of requirements. This approach is p

This approach is 

the cleanest approach in terms of the cleanest approach in terms of honouring honouring consisten

consisten

between the different parts of the standard, between the different parts of the standard,” 

”

 “...but there should be a case made that XML but there should be a case made that XML-zing Pa

zing Pa



“The value of Part 2 is also enab The value of Part 2 is also enabling the future user base to m

ling the future user base to m

a modern messaging framework that rn messaging framework that is not entangled with the 

 is not entangled with the 

design of Part 1. design of Part 1.”

 “...should be likened to the move between EDI and XML should be likened to the move between EDI and XML”

 “...

dec

ouple d

ata from the e ta from the e

nvelope/messaging, transact

lope/messaging, transact

command layers of the stack.” 

command layers of the stack.

”

and

-of-itself does not deliver significant value to the ex

itself does not deliver significant value to the ex

future user base. future user base.

”
202.3 Conformance (1 of 3

Systems claiming conformance with this standard shall im

the transmitting and/or receiving of record types as dethis standard. Systems claiming conformance are not rimplement every record type specified herein. At a mithey must be capable of transmitting and receiving records. However, in order for a transaction to be me

there must be at least one additional type of record inc

there must be at least one additional type of record inc

The implementer must document the record types sup

The implementer must document the record types sup

terms of transmitting and/or receiving. Those record 

terms of transmitting and/or receiving. Those record 

implemented shall be ignored by the conforming system implemented shall be ignored by the conforming systemreceiving a transaction. receiving a transaction.

202.3 Conformance (1 of 3

Systems claiming conformance with this standard shall im

the transmitting and/or receiving of record types as dethis standard. Systems claiming conformance are not rimplement every record type specified herein. At a mithey must be capable of transmitting and receiving records. However, in order for a transaction to be me
202.3 Conformance (2 of 3

Implementers are expected to extend this standard b

supplying substitution elements for the abstract el<itl:UserDefinedFields>, <itl:RecordImage>, <itl:RecordMinutiae>, <itl:DomainDefinedDescriptiveText>, and/or <itl:OtherDescriptiveText>. The substitution eleme

be created in a separate user be created in a separate user-declared namespace. The 

declared namespace. The 

of the substitution elements must be well of the substitution elements must be well-formed XML 

formed XML 

should follow NIEM rules for extending the National should follow NIEM rules for extending the NationalInformation Exchange Model. Implementers may mo

Information Exchange Model. Implementers may mo

xmlns: and import attributes to reference user : and import attributes to reference user-defined defined

namespaces and extension schema. The namespaces and extension schema. The minOccurs minOccurs a

maxOccurs maxOccurs attributes in the ITL constraint schema ver

attributes in the ITL constraint schema ver

ansi

-nist.xsd nist.xsd may be modified to facilitate use of NIEM may be modified to facilitate use of NIEM 

elements in user elements in user-defined blocks. defined blocks.

202.3 Conformance (2 of 3

Implementers are expected to extend this standard b

supplying substitution elements for the abstract el<itl:UserDefinedFields>, <itl:RecordImage>, <itl:RecordMinutiae>, <itl:DomainDefinedDescriptiveText>, and/or <itl:OtherDescriptiveText>. The substitution eleme
202.3 Conformance (3 of 3

202.3 Conformance (3 of 3

Implementers may not introduce new elements excep

Implementers may not introduce new elements excep

the substitution elements described above, nor ma

the substitution elements described above, nor ma

change the order or structure of elements defined 

change the order or structure of elements defined 

standard. standard.

The root element, The root element,

<itl:NISTBiometricInformationExchangePackage itl:NISTBiometricInformationExchangePackage>, m

>, m

included as a payload in a larger package. included as a payload in a larger package.

All required elements must be present in a conformin

All required elements must be present in a conformin

instance document even if the standard instance document even if the standard’s schema d

s schema 

strictly enforce the requirement. strictly enforce the requirement.
Request for Change to Conform

in DHS

-OCIO

-7 (and 10)

Request for Change to Conform

in DHS

-OCIO

-7 (and 10) 



‘Perhaps this specification could either be

Perhaps this specification could either be 

 (a) relaxed in terms of conformance rules to 

(a) relaxed in terms of conformance rules to 

some of the less some of the less

-prescriptive/rigid data exch

prescriptive/rigid data exch

scenarios or scenarios or

 (b) extended to support several logical tiers o

(b) extended to support several logical tiers 

conformance, the highest of which would be 

conformance, the highest of which would b

current definition of conformance; perhaps 

current definition of conformance; perhaps 

distinguish distinguish

“transaction/exchange conforma

transaction/exchange conforma

from

“data conformance. data conformance.”’
DHS Issue with Single Root Ele

(DHS

-OCIO

-9 and 11)

layers

DHS Issue with Single Root Ele

(DHS

-OCIO

-9 and 11) 

layers 

 Having a single root element versus Having a single root element versus deco

deco

of the message transaction layer and the d

of the message transaction layer and the d
DHS Record Type DHS Record Type

-1 

Concerns Concerns

(DHS

-OCIO

-12, 14, 17, 18) 12, 14, 17, 18)

 Requirement of Type Requirement of Type

-1 records problem 

1 records problem 

some applications some applications
TSC’s Specific Issues with Typ

Specific Issues with Ty

(1 of 4) (1 of 4)

Data redundant for TSC use; make optional?: (1 of 2) Data redundant for TSC use; make optional?: (1 of 2)

 <ansi-nist:TransactionDate nist:TransactionDate>

 (1.005, DAT; TSC (1.005, DAT; TSC-2)

 <ansi-nist:TransactionDestinationOrganization nist:TransactionDestinationOrganization>

 (1.007, DAI; TSC (1.007, DAI; TSC-3)

 <ansi-nist:TransactionOriginatingOrganization nist:TransactionOriginatingOrganization>

 (1.008, ORI; TSC (1.008, ORI; TSC-4)

 <ansi-nist:TransactionControlIdentification nist:TransactionControlIdentification>

 (1.009, TCN; (1.009, TCN; TSC-5)

 <ansi-nist:TransactionMajorVersionValue nist:TransactionMajorVersionValue>

 (1.002, VER; TSC (1.002, VER; TSC-8)

 <ansi-nist:TransactionMinorVersionValue nist:TransactionMinorVersionValue>

 (1.002, VER; TSC (1.002, VER; TSC-9)
TSC’s Specific Issues with Typ

Specific Issues with Ty

(2 of 4) (2 of 4)

Data redundant for TSC use; make optional?: 

Data redundant for TSC use; make optional?: 

 <ansi-nist:TransactionCategoryCode nist:TransactionCategoryCode>

 (1.004, TOT; TSC (1.004, TOT; TSC-11)

 <ansi-nist:TransactionContentSummary nist:TransactionContentSummary>

 (1.003, CNT; TSC (1.003, CNT; TSC-12-TSC-15) <ansi-nist:ContentFirstRecordCategoryCode> nist:ContentFirstRecordCategoryCode> <ansi-nist:ContentRecordCount nist:ContentRecordCount> <ansi-nist:ContentRecordSummary> nist:ContentRecordSummary>

 <ansi-nist:ImageReferenceIdentification> nist:ImageReferenceIdentification> <ansi-nist:RecordCategoryCode> nist:RecordCategoryCode>
TSC’s Specific Issues with Typ

Specific Issues with Ty

(3 of 4) (3 of 4)

Device specific; make optional?: Device specific; make optional?:

 <ansi-nist:NativeScanningResolutionVal

nist:NativeScanningResolutionVal

 (1.011, NSR; TSC (1.011, NSR; TSC-6)

 <ansinist:NominalTransmittingResolutionValu

nist:NominalTransmittingResolutionValu

 (1.012, NTR; TSC (1.012, NTR; TSC-7)
TSC’s Specific Issues with Typ

Specific Issues with Ty

(4 of 4) (4 of 4)

Remove optional field?: Remove optional field?:

 <ansi-nist:TransactionPriorityValue nist:TransactionPriorityValue>

 (1.006, PRY; TSC (1.006, PRY; TSC-10)
High-Level Element for Eac

Level Element for Eac

Logical Record Type? (TSC Logical Record Type? (TSC-





For Types For Types- 3, 4, 5, 6, 7, 8, 10, 13, 14, 115

3, 4, 5, 6, 7, 8, 10, 13, 14, 115

and 99

Draft standard has them all under Draft standard has them all underPackageImageRecordType PackageImageRecordType.

Want the system to know what type of imag

Want the system to know what type of imag

record before going through another level. record before going through another level.
DHS Issue with Resolution DHS Issue with Resolution

Requirements Requirements

(DHS

-OCIO

-15)

 Type

-3 through Type 3 through Type

-6 

 Allow for unknown resolution of fingerprin

Allow for unknown resolution of fingerprin
TSC Type-10 Issues

TSC: “For many of the facial records that TSC h

TSC Type-10 Issues 

TSC: “For many of the facial records that TSC h

only have the JPEG image with no image meta

only have the JPEG image with no image meta

other then those in the JPEG header. other then those in the JPEG header.”

 <ansi-nist:CaptureDate nist:CaptureDate> 

 (10.005, PHD; TSC (10.005, PHD; TSC-17)

 May be missing (whole or part), may be classified May be missing (whole or part), may be classified

 <ansi-nist:CaptureOrganization nist:CaptureOrganization>

 (10.004, SRC; TSC (10.004, SRC; TSC-18) May be classified May be classified
DHS-OCIO-16 and 19 and TSC 16 and 19 and TS

 Use ofGIFs

 Use ofGIFsin user in user-defined record types defined record types
As We Discuss Options, Consid

As We Discuss Options, Consid

 Do your operations include a need for Do your operations include a need for

interoperability with legacy users and data

interoperability with legacy users and dat

Is the value of smaller data Is the value of smaller data packages greater 

packages greater 

value of interoperability? value of interoperability?

Is the value of smaller data Is the value of smaller data packages greater 

packages greater 

cost of conversion between different version

cost of conversion between different version

biometric packages? biometric packages?
Internal Data Exchange Internal Data Exchange
Internal v. External Data Exch

Internal v. External Data Exch
Options Options

 1–Part 2 is an XML version of Part 1 Part 2 is an XML version of Part 1 2–Part 2 differs from Part 1 by removing Rec

Part 2 differs from Part 1 by removing Rec

Type-1 

 3–Part 2 differs from Part 1 by making Part 1 Part 2 differs from Part 1 by making Part 1

requirements optional, such as Type requirements optional, such as Type-1 records 

1 records 

mandatory fields mandatory fields

 4–Multiple levels of conformance Multiple levels of conformance 5–If meta If meta-data not needed, use ANSI INCITS 

data not needed, use ANSI INCIT

ISO/IEC standards for exchanging data ISO/IEC standards for exchanging data
Options Options

 1–Part 2 is an XML version of Part 1 Part 2 is an XML version of Part 1

 Pro: Assists a large number of legacy users 

Assists a large number of legacy users 

NIST standard convert between formats NIST standard convert between formats

 Con: Creates some extra overhead for new a

Con: Creates some extra overhead for new a

future users of the XML version of the NIS

future users of the XML version of the NIS

standard standard

 But users such as DHS & TSC will still be able t

But users such as DHS & TSC will still be able t

standard with some redundancy and use of bogu

standard with some redundancy and use of bogu

where meta where meta-data is missing or classified data is missing or classified

 Comment sections can also be used to explain th

Comment sections can also be used to explain t
Options Options

2–Part 2 differs from Part 1 by removing 

Part 2 differs from Part 1 by removing 

Type-1 

 Pro: Efficient design Pro: Efficient design –Data is redundant fo

Data is redundant fo

new users new users’applications where biometric data 

applications where biometric dat

of larger package of larger package

 Con: Problematic for Part 1 conversion and 

Con: Problematic for Part 1 conversion and 

who are using both formats who are using both formats
Options Options

 3–Part 2 differs from Part 1 by making Part 1 Part 2 differs from Part 1 by making Part 1

requirements optional, such as Type requirements optional, such as Type-1 records 

1 records 

mandatory fields mandatory fields

 Pro: More flexible for different users needs More flexible for different users needs 

 Users such as FBI can more heavily rely on thei

Users such as FBI can more heavily rely on thei

(e.g. EBTS) to make optional A/N XML fields 

(e.g. EBTS) to make optional A/N XML fields 

mandatory mandatory

 Con: Lack of interoperability Lack of interoperability –May be problemati

May be problemati

conforming to different profiles wish to exchange d

conforming to different profiles wish to exchange d

 May decide to make all or some mandatory fields op

May decide to make all or some mandatory fields o
Options Options

 4–Multiple levels of conformance Multiple levels of conformance

 Pro: More flexible for different users needs Pro: More flexible for different users needs

 Users such as FBI can specify in their profile (e.

Users such as FBI can specify in their profile (e.

which level of conformance is required which level of conformance is required

 Con: Lack of interoperability Con: Lack of interoperability –May be problemati

May be problemati

conforming to different levels wish to exchange dat

conforming to different levels wish to exchange dat

 Could address different levels of conformance in a 

Could address different levels of conformance in a 

document document
Pro: Fits needs of some users while not making ch

negatively impact legacy users of the NIST standard 

5 – If meta

-data not needed, use ANSI INCITS 

ISO/IEC standards for exchanging data 





Options Options

 5 – If meta

-data not needed, use ANSI INCIT

ISO/IEC standards for exchanging data

 Pro: Fits needs of some users while not making ch

negatively impact legacy users of the NIST standard

 Con: Lack of interoperability Con: Lack of interoperability

–May be problematic 

May be problematic 

of different standards wish to exchange data of different standards wish to exchange data
Options Options

 1–Part 2 is an XML version of Part 1 Part 2 is an XML version of Part 1 2–Part 2 differs from Part 1 by removing Rec

Part 2 differs from Part 1 by removing Rec

Type-1

 3–Part 2 differs from Part 1 by making Part 1 Part 2 differs from Part 1 by making Part 1

requirements optional, such as Type requirements optional, such as Type-1 records 

1 records 

mandatory fields mandatory fields

 4–Multiple levels of conformance Multiple levels of conformance 5–If meta If meta-data not needed, use ANSI INCITS 

data not needed, use ANSI INCIT

ISO/IEC standards for exchanging data ISO/IEC standards for exchanging data