February 22, 2008

ANSI/NIST-ITL 1-2007 **PART 2 XML**

*Modification Notes*

Author: Gerry Coleman

## Overview

The modifications described here have been applied to the proposed
documentation package published 9/5/2007. The reasons for the
modifications are these:

A.  The \<ansi-nist:ImageQuality\> element is insufficient to handle
    latent, fingerprint and palmprint quality data because it lacks a
    finger or palm position subelement.

B.  The NIEM program office is unable to make corrections to two
    important errors in the ansi-nist: namespace. (1) Three subelements
    in \<NISTStandardMinutiaeType\> need to be moved to
    \<MinutiaType\>. (2) The \<PCSCodeSimpleType\> enumerates codes for
    fingerprint *patterns* when it should simply have the enumerations
    "T" and "U" (for code sources "table" and "user-defined").

C.  The NIEM program office is unable to add to the ansi-nist: namespace
    additional needed elements for fingerprint and iris images.

D.  Minor repairs to the instance example.

E.  User-defined fields have been changed to abstract elements to allow
    for substitution (rather than defining content as ##any).

## Image Quality Modifications

IRIS. The iris quality element has three subelements that exactly match
\<ansi-nist:ImageQuality\>. There is no need to modify the existing
structure. There is no "iris position" subelement comparable to the
finger and palm problem.

FACE. The subject quality score element has three subelements that
exactly match \<ansi-nist:ImageQuality\>. There is no need to modify the
existing structure. There is no "subject position" subelement comparable
to the finger and palm problem.

SMT. Part 1 has no quality element for SMT's.

FINGERS and PALMS.

> I wanted to create a harmonious fix, something for palms that would
> parallel the element for fingers, and would contain the same three
> subelements for quality used for iris and face.
>
> The element \<ansi-nist:FingerprintImageQualityType\> was rejected
> because there is no parallel construction for palms, and because it
> does not use the same three elements as \<ansi-nist:ImageQuality\>.
> The segmentation quality element uses the different set of three, but
> I didn't change it (one might imagine that segmentation quality is
> different from image quality?).
>
> Two new elements and types were created:
>
> \<itl:FingerprintImageQuality\> \<itl:FingerprintImageQualityType\>
>
> \<itl:PalmprintImageQuality\>\
> \<itl:PalmprintImageType\>
>
> Both types were *based* on \<ansi-nist:ImageQuality\>, and one has a
> \<FingerPositionCode\>, the other a \<PalmPositionCode\>. This
> produces a complex element that (except for order of subelements)
> exactly matches Part 1's FQM and PQM.

LATENTS. Latents can be either fingers or palms, and the quality element
requires either a finger position from Table 12 or a palm position from
Table 35. My solution for this is for the Type 13 Latent record to
include either a \<FingerprintImage\> or a \<PalmprintImage\>. The
quality measure follows automatically from this decision as
\<FingerprintImage\> contains a \<FingerprintImageQuality\> element with
a finger position code, and \<PalmprintImage\> contains a
\<PalmprintImageQuality\> element with a palm position code. This
eliminates the need for a \<LatentprintQuality\> element that could
contain either a finger or palm position code.

## Repairing Minutiae and Minutia Types

These three elements need to be moved from the plural Minutiae complex
to the singular Minutia complex:

> \<ansi-nist:MinutiaQualityValue\>\
> \<ansi-nist:MinutiaCategory\>\
> \<ansi-nist:MinutiaRidgeCount\>

Although I *could have* constructed itl: elements *based* on their
ansi-nist: counterparts and appended the three to the singular complex,
I elected to fully redefine these

> \<itl:Minutiae\>\
> \<itl:MinutiaeNISTStandard\>\
> \<itl:MinutiaDetail\>

The adopted approach (full redefinition of the complex elements) means
that when NIEM makes its repairs, the only adjustment implementers will
have to make is to change the namespace like so

> \<ansi-nist:Minutiae\>\
> \<ansi-nist:MinutiaeNISTStandard\>\
> \<ansi-nist:MinutiaDetail\>

The rejected approach (using what NIEM already has in place and deriving
a fix) would require implementers to re-order elements in addition to
changing the namespace.

## Repairing the PCS Code enumerations

The affected element is \<FingerPatternCodeSourceCode\>. Because it is a
part of \<Minutiae\>, it benefits from the approach taken in the section
above. That is, I was able to create these subelements and types

> \<itl:MinutiaeFingerPatternDetail\>\
> \<itl:FingerPatternCodeSourceCode\>\
> \<itl:PCSCodeType\>\
> \<itl:PCSCodeSimpleType\>

The latter has enumerations of "T" and "U".

When fixed, implementers will only have to change the namespace
reference.

## Accommodating additional elements in the Image types

If it is a good idea to simplify the work of implementers when NIEM is
updated, then that same principle applies to

> \<itl:FingerprintImageType\>\
> \<itl:PalmprintImageType\> (new)\
> \<itl:IrisImageType\>

In the earlier proposal, I had *based* \<itl:FingerprintImageType\> on
\<ansi-nist:FingerprintImageType\> and added the additional needed
elements.

In this proposal, I have completely redefined each of these types, and
*based* them on \<ansi-nist:NISTImageType\> which will not change when
NIEM is upgraded. This means that implementers will only have to change
the namespace reference.

It also means that NIEM should adopt the full definition of these three
elements as proposed here.

I also took the liberty of re-ordering all of the subelements so they
match as nearly possible the order of elements in Part 1.

## Minor repairs 

-   In instance example, in record types 10, 13, 14, 15, 16, and 17, I
    changed \<ImageCompressionAlgorithmCode\> to
    \<ImageCompressionAlgorithmText\>. This fixes the problem of using
    "JPEGB" or "NONE" as a value when the code enumerations only contain
    numerics.

-   In instance example record types 3, 4, 5, and 6, I changed the
    values for GCA and BCA to the specification's "recommended" values.

-   In the schema, I stepped all of the "import location" references
    down a directory level. This allows all the NIEM schema to be in a
    single subdirectory.

## Modifications for Version "e"

## User-defined Fields

The elements \<itl:DomainDefinedDescriptiveText\>,
\<itl:OtherDescriptiveText\>, and \<itl:UserDefinedFields\> have been
defined as abstract, and there is no defined type. Implementers will be
expected to define their own substitutions.

The element \<itl:UserDefinedImage\> (used only in the Type 07 record)
was deleted altogether. In the instance example for Type 07, the
abstract element \<ansi-nist:RecordImage\> was inserted. Implementers
will be expected to define their own substitution.

"Example" substitutions were created for insertion into the sample
instance document.

## Accommodations for Vendor Minutiae Blocks

Previous drafts did not provide a way for alternate definitions of
minutiae blocks in the Type 09 record. The proposed modification
parallels the structure used for multiple image definitions. Just as the
\<itl:PackageImageRecord\> contains an abstract
\<ansi-nist:RecordImage\>, the record element
\<itl:PackageMinutiaeRecord\> was modified to contain an abstract
\<itl:RecordMinutiae\>.

The element \<itl:Minutiae\> was redefined to be part of the
substitution group for \<itl:RecordMinutiae\>.

Two elements \-- \<ansi-nist:MinutiaeFormatNistStandardIndicator\> and
\<ansi-nist:MinutiaeImpressionCaptureCategoryCode\> were "extracted"
from \<itl:MinutiaeNISTStandard\> and promoted to the record level (see
PackageMinutiaeRecordType). This was done because the standard requires
these two elements to be present even when vendors create substitute
data blocks. In this manner, the abstract element represents only the
portion of the record that is substitutable.

This change will allow implementers to extend the standard, substituting
different, vendor-defined blocks that substitute for
\<itl:RecordMinutiae\>.

## Image Quality adjustments

The element \<itl:FingerprintImageQuality\> is now defined as type
\<ansi-nist:FingerprintImageQualityType\> rather than trying to define a
new itl: type.

An \<itl:PalmprintImageQualityType\> was created to exactly mirror the
construction of \<ansi-nist:FingerprintImageQualityType\>. Although the
base type is awkwardly constructed, the actual instance data is
perfectly symmetrical.

## Polygon repair

The standard requires Field 14.025 (ASEG) to have a subfield with a
count of the number of coordinates. That subfield has been missing from
previous iterations of this draft. I added
\<itl:PositionPolygonVertexQuantity\> to
\<itl:FingerprintImageSegmentPositionPolygon\>.

## Constraint schema

The NIEM file ansi-nist.xsd was copied (in place, same directory) to
become ansi-nist_itl_constraint.xsd. I adjusted the minOccurs and
maxOccurs wherever possible to enforce the required and optional
conditions of the standard.

The NIEM file and the ITL constraint file contain exactly the same set
of elements. Only the "occurs" attributes were changed.

In some cases it is not possible to enforce the standard in the schema.
For example, the \<ansi-nist:ImageColorSpaceCode\> is required in the
Type-10 record, but not allowed at all in a Type-14 record. The reverse
is true for \<ansi-nist:ImageBitsPerPixelQuantity\>. So, they both have
to be minOccurs="0" under \<ansi-nist:NISTImageType\>.

I added comments to the constraint file to identify elements that are
not used, and where possible set them to maxOccurs="0". I also added
comments to cross-reference the XML elements to their Part 1
counterparts.

The "xsd:import schemaLocation" attribute in the main package schema was
changed to point to the ITL constraint file rather than the NIEM
ansi-nist.xsd.

## Face Image

The Field 10.23 Photo acquisition source (PAS) appears at first to be a
simple element with a value taken from a chart, Table 21. That is the
way it is constructed in \<ansi-nist:ImageCaptureDetail\> as the element
\<ansi-nist:CaptureSourceCode\>. Values are enumerated in the
PASCodeType.

Unfortunately, the documentation allows for a free-text value to be
reported as a second sub-item if the value of the main code is "VENDOR".
This can't be done with existing ansi-nist: elements.

I created an \<itl:FaceImage\> element based on \<ansi-nist:FaceImage\>
and extended it with a single element
\<itl:FaceImageAcquisitionSource\>. The new acquisition source element
has two child elements: \<ansi-nist:CaptureSourceCode\> and a new
\<itl:CaptureSourceDescriptionText\> defined as a string type.

This required changes to the instance document and the element
spreadsheet chart.