English

How To: Customize GIS Portal Toolkit (GPT) validation

Summary

Deciding what validation rules to enforce against documents published to a portal is important because validation affects the quality of the metadata documents available in the portal. Before validation is altered, the purpose for doing so should be clear. Is it a matter of making a specific set of metadata available? Is the current validation too stringent? Could some validation rules be turned off while others are left in place? Or should validation be turned off entirely, so all documents publish without validation?

It is best to publish metadata that passes all validation without altering the validation rules. Providing correctly formatted metadata documents is preferable to changing the rules to fit the metadata. However, perfect metadata is not always feasible. Instructions provided describe how to modify validation so that certain documents that currently don't publish can be published successfully.

Procedure

Validation rules are defined in the 'xml_apply_validation.xslt' file. They can easily be changed by commenting or uncommenting certain portions of this file. Commenting and uncommenting the file is not difficult; however, adding further functionality and new lines of code requires experience with XSLT programming.

  1. Make a list of where validation fails when attempting to publish a metadata document to the portal. Details on why the document fails to publish are given in the errors that appear during the publishing process. The following are examples of possible validation errors:

    Unable to publish document.
    Your metadata document did not pass Content Validation: filename

    Rule: Check the value and presence for field abstract
    Status: error
    Reason: The required field is not populated, present or contains incorrect information
    Metadata Element: /metadata/idinfo/descript/abstract |
    /metadata/idinfo/descript/purpose | /metadata/idinfo/descript/supplinf

    Rule: Check the value and presence for field subject
    Status: error
    Reason: The required field is not populated, present or contains incorrect information
    Metadata Element: /metadata/idinfo/keywords/theme/themekey

    Rule: Check the value and presence for field street address
    Status: error
    Reason: The required field is not populated, present or contains incorrect information
    Metadata Element: /metadata/idinfo/ptcontac/cntinfo/cntaddr/address

  2. Open the 'xml_apply_validation.xslt' file, located at '\\<tomcat installation directory>\webapps\Portal\WEB-INF\classes\com\esri\gpt\catalog\adapters' in a text editor, such as Notebook.
  3. Scroll down to the following lines:

    Code:

    <!--xsl:call-template name="check-origin"/-->
    <xsl:call-template name="check-fileIdentifier"/>
    <xsl:call-template name="check-title"/>
    <xsl:call-template name="check-abstract"/>
    <xsl:call-template name="check-subject"/>
    <xsl:call-template name="check-restype"/>
    <xsl:call-template name="check-date"/>
    <xsl:call-template name="check-contact"/>
    <!-- special case for extent - must be 4 elements present (to define the bounding box).
    Also checks for Lat/Long (i.e. 'Degrees') for coordinate values. -->
    <xsl:call-template name="check-bnd"/>

  4. This code is the core of the validation file - it tells the portal what fields to validate in the metadata document. The example errors in step 1 show that the portal is throwing errors when it is validating against the abstract, the theme keyword, and the contact information.

    - The validation error for the abstract is triggered when '<xsl:call-template name="check-abstract"/>' is executed.
    - The validation error for the themekey is triggered when '<xsl:call-template name="check-subject"/>' is executed.
    - The validation error for the contact information is triggered when '<xsl:call-template name="check-contact"/>' is executed.
  5. Notice that the first <xsl:call-template ...> is commented out (the call to "check-origin"). This means that the GPT does not validate against the existence of the origin field in a metadata document. It is possible to turn off validation for other parts of the metadata by commenting out the calls in this core section.
  6. Decide what fields should be commented out. For example, if the abstract and themekey should remain validated, but the contact info rules are too stringent and could be commented out, then the core of this XSLT file would be changed to the following:

    Code:

    <!--xsl:call-template name="check-origin"/-->
    <xsl:call-template name="check-fileIdentifier"/>
    <xsl:call-template name="check-title"/>
    <xsl:call-template name="check-abstract"/>
    <xsl:call-template name="check-subject"/>
    <xsl:call-template name="check-restype"/>
    <xsl:call-template name="check-date"/>
    <!--xsl:call-template name="check-contact"/-->
    <!-- special case for extent - must be 4 elements present (to define the bounding box).
    Also checks for Lat/Long (i.e.'Degrees') for coordinate values. -->
    <xsl:call-template name="check-bnd"/>

  7. Comment or uncomment what is necessary, and save the file. Refresh the portal Web site, and publish a document to the portal. The errors concerning the fields that are commented out should no longer appear.

Related Information