RE: Proposal: To Provide a mechanism to dynamically extract valid ation errors

["Murphy, Eric" <er...@pfc.cfs.nrcan.gc.ca>]

Dutta:
 
Your proposal sounds good.  
 
Your description of the current scenario doesn't sound exactly correct
however.  You can definitely get more than the messages from the currently
retrieved error object.  The problem of course is that the information you
need to identify missing elements and attributes is not available or it is
buried in the message.  While it can be parsed from the message we don't
believe relying on the exact format of an error message is a reliable way to
find this information (and of course at times it is not there at all).
 
I would be very happy to have a reliable way to get a QName for missing
attributes and elements.  Having a constant to identify it as an attribute
or element seems like a good idea.
 
Thanks for working on this.  Getting better error information upon
validation is quite important to us.
 
Eric Murphy 
Software Developer
Pacific Forestry Centre
Canadian Forest Service
Natural Resources Canada

  _____  

From: Dutta Satadip [mailto:s-dutta@sbcglobal.net] 
Sent: Sunday, February 01, 2004 1:32 AM
To: xmlbeans-dev@xml.apache.org; xmlbeans-users@xml.apache.org
Cc: dmitri.colebatch@bea.com; eric.murphy@bea.com; david.bau@bea.com
Subject: Proposal: To Provide a mechanism to dynamically extract validation
errors



Hello,

There have been requests made(to the mailing list) to provide an enhancement
to dynamically extract xml schema validation errors. Based on the emails, I
have the following proposal.  

 

Feedback on the proposal would be greatly appreciated.

With Regards

Dutta:)

 

 

Proposal: Provide a mechanism to dynamically extract validation errors

 

Current Scenario: When errors occur during XML schema validation, the
XMLError object is populated with a message. Currently, the xmlOptions class
allows us to set a errorlistener. Once validation is complete the error list
can be extracted. Currently only the messages (String can be extracted). The
validator uses the emitFieldError method to populate the validation error
messages. 

 

 

 

Suggested enhancement:

 

Create a subclass of XMLError and add additional attributes and methods to
retrieve them.

 

public class XmlValidationError extends XmlError

{

    private QName  _offendingQName;

    private QName[]  _expectedQNames;

    private int _errorType;

      /*

            1 = Incorrect Attribute 

2 = Incorrect Element

 

      */

    private String badSchemaType;

 

    public static XmlValidationError addDetails(XmlError xmlerror, QName
offendingQname , List expectedQNames, int errorType , String badSchemaType)

 

   public QName getOffendingName()

   public QName[] getExpectedNames()

   public int getErrorType()

   public String getBadSchemaType()

 }

 

 

The XmlOptions class will also be modified to include another option -a
method similar to setErrorListener.

 

The new method will be 

 

    public XmlOptions setValidationErrorListener (Collection c) 

 

setValidationErrorListener will have the same use case model as
setErrorListener. The collection will contain XMLValidationError objects for
each validation error. The XMLValidationError object would be populated
during the validation (Validator).

 

This will allow users who require dynamic error extraction to use code
similar to the snippet below

 

XmlOptions validateOptions = new XmlOptions();

ArrayList errorList = new ArrayList();

 validateOptions. setValidationErrorListener (errorList);

 

// Validate the XML.

boolean isValid = newEmp.validate(validateOptions);

     * 

     * // If the XML isn't valid, loop through the listener's contents,

     * // printing contained messages.

     * if (!isValid)

     * {

          for (int i = 0; i < errorList.size(); i++)

         {

             XmlValidationError error =
(XmlValidationError)errorList.get(i);

             //extract details as necessary

 

         }