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

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.