Schemas/NIST-ITL
From Code Synthesis Wiki
| Revision as of 18:50, 29 March 2009 Boris (Talk | contribs) ← Previous diff |
Current revision Admin (Talk | contribs) (Reverted edits by Otepuxy (Talk); changed back to last version by Boris) |
||
| Line 7: | Line 7: | ||
| This is caused by two schemas (ansi-nist.xsd and ansi-nist_itl_constraint.xsd) that define the same set of types both being imported from different sub-schemas when loading the top-level ITL-2007f-Package.xsd schema. For background and more information on this issue, see the [http://codesynthesis.com/pipermail/xsd-users/2009-March/002282.html "Compiling the NIST-ITL schema with XSD"] thread on the xsd-users mailing list. | This is caused by two schemas (ansi-nist.xsd and ansi-nist_itl_constraint.xsd) that define the same set of types both being imported from different sub-schemas when loading the top-level ITL-2007f-Package.xsd schema. For background and more information on this issue, see the [http://codesynthesis.com/pipermail/xsd-users/2009-March/002282.html "Compiling the NIST-ITL schema with XSD"] thread on the xsd-users mailing list. | ||
| - | The easiest way to resolve this issue is to modify the niem-code.xsd and jxdm.xsd schemas to import ansi-nist_itl_constraint.xsd instead of ansi-nist.xsd. With this change the ITL schema can be compiled in the file-per-type mode without any problems. It is also possible to achieve the same effect without modifying the schemas. During compilation you can use the --location-map XSD compiler option to re-map ansi-nist.xsd to ansi-nist_itl_constraint.xsd. If you enable XML Schema validation during parsing then you will also need to setup your own XML-to-DOM parsing and install a custom entity resolver which returns ansi-nist_itl_constraint.xsd instaed of ansi-nist.xsd when requested by the parser. | + | The easiest way to resolve this issue is to modify the niem-code.xsd and jxdm.xsd schemas to import ansi-nist_itl_constraint.xsd instead of ansi-nist.xsd. With this change the ITL schema can be compiled in the file-per-type mode without any problems. It is also possible to achieve the same effect without modifying the schemas. During compilation you can use the --location-map XSD compiler option to re-map ansi-nist.xsd to ansi-nist_itl_constraint.xsd. If you enable XML Schema validation during parsing, then you will also need to setup your own XML-to-DOM parsing and install a custom entity resolver which returns ansi-nist_itl_constraint.xsd instead of ansi-nist.xsd when requested by the parser. |
| Another issue with the ITL schema is its use of substitution groups as some sort of application-significant IDs rather than just a way to specify the element types. For example, elements PackageUserDefinedImageRecord, PackageLantentImageRecord, etc., all substitute PackageDataRecord but are all of the same PackageImageRecordType type. During serialization the generated code uses object model types to automatically figure out which element name to use based on the substitution group information from the schemas. As a result, the generated code always uses the first element name from the above group since the object types | Another issue with the ITL schema is its use of substitution groups as some sort of application-significant IDs rather than just a way to specify the element types. For example, elements PackageUserDefinedImageRecord, PackageLantentImageRecord, etc., all substitute PackageDataRecord but are all of the same PackageImageRecordType type. During serialization the generated code uses object model types to automatically figure out which element name to use based on the substitution group information from the schemas. As a result, the generated code always uses the first element name from the above group since the object types | ||
| Line 18: | Line 18: | ||
| * [[Media:Nist-itl-2007f.tar.gz|nist-itl-2007f.tar.gz]] | * [[Media:Nist-itl-2007f.tar.gz|nist-itl-2007f.tar.gz]] | ||
| * [[Media:Nist-itl-2007f.zip|nist-itl-2007f.zip]] | * [[Media:Nist-itl-2007f.zip|nist-itl-2007f.zip]] | ||
| + | |||
| + | See also the [[Talk:Schemas/NIST-ITL|Discussion page]] for this schema. | ||
Current revision
This page contains information on using the ANSI/NIST-ITL (Data Format for the Interchange of Fingerprint, Facial, & Other Biometric Information) schema with XSD.
When trying to compile the 2007f version of this schema with XSD, you may get the following error:
type 'http://niem.gov/niem/ansi-nist/2.0:FingerprintType' is not found
This is caused by two schemas (ansi-nist.xsd and ansi-nist_itl_constraint.xsd) that define the same set of types both being imported from different sub-schemas when loading the top-level ITL-2007f-Package.xsd schema. For background and more information on this issue, see the "Compiling the NIST-ITL schema with XSD" thread on the xsd-users mailing list.
The easiest way to resolve this issue is to modify the niem-code.xsd and jxdm.xsd schemas to import ansi-nist_itl_constraint.xsd instead of ansi-nist.xsd. With this change the ITL schema can be compiled in the file-per-type mode without any problems. It is also possible to achieve the same effect without modifying the schemas. During compilation you can use the --location-map XSD compiler option to re-map ansi-nist.xsd to ansi-nist_itl_constraint.xsd. If you enable XML Schema validation during parsing, then you will also need to setup your own XML-to-DOM parsing and install a custom entity resolver which returns ansi-nist_itl_constraint.xsd instead of ansi-nist.xsd when requested by the parser.
Another issue with the ITL schema is its use of substitution groups as some sort of application-significant IDs rather than just a way to specify the element types. For example, elements PackageUserDefinedImageRecord, PackageLantentImageRecord, etc., all substitute PackageDataRecord but are all of the same PackageImageRecordType type. During serialization the generated code uses object model types to automatically figure out which element name to use based on the substitution group information from the schemas. As a result, the generated code always uses the first element name from the above group since the object types are the same.
One way to overcome this in the C++/Tree mapping is to customize the xml_schema::type class (which is the base type for all the generated classes) by adding a custom type id member (which is just the substituting element name). This type id is automatically extracted during parsing, can be queried/modified by the application, and is used during serialization to make sure the right element name is used. With this change the serialized XML is equivalent to the original.
The following two packages contain the fixed-up NIST-ITL 2007f schemas, custom xml_schema::type implementation, the test driver, XSD option files, as well as the README file which explains how to compile everything:
See also the Discussion page for this schema.
