RE: Fwd: Proposal: To Provide a mechanism to dynamically extract validation errors

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

Dutta -
 
Your example represents accuratly the problems we are having.  Your proposal
appears to address the problem.  Having the SchemaType of the offending
element or attribute is just what we need.
 
Because our applications are internationalized messages are not useful to
us.  Certainly parsing messages to find element and attribute names is
unreliable.  Based on the schema type we can figure out where the error is
occuring and what field it represents in the user interface.
 
Eric Murphy
Pacific Forestry Centre
Canadian Forest Service

  _____  

From: Dutta Satadip [mailto:s-dutta@sbcglobal.net] 
Sent: Wednesday, February 04, 2004 11:32 PM
To: xmlbeans-user@xml.apache.org
Subject: Re: Fwd: Proposal: To Provide a mechanism to dynamically extract
validation errors



Hi Toby,

There are a lot of questions that are cascading so let me try to address the
most basic one- how do we use this?

Lets say the user enters some peice of data that will construct a order. The
order is repesented as an XML behind the covers. The order has different
parts and each of them have specific types etc.

<order>

<lineItem>

<Name> </name>

</Quantity> <Quantity>

<Description> <Description>

</lineitem>

<order>

 Now lets say that there is an element quantity. The uses instead of
entering a quanitty leaves it blank. asuuming that blanks are translated as
missing information, you try to validate this. In this case a element is
missing so you will get the XMLValdationError .

Once you retrieve the XMLValdationError

1. Check the errorType ( This will tell you what kind of error it is). 

You will be able to tell if this is a missing element/attribute etc, by
looking at the errorType. For the purpose of the example the errorType =2

2. badSchemaType can be of type SchemaType(The proposal had it as a string
but I can most definitely define it as SchemaType). This way you can get a
handle on what type has the problem.

For the example the badSchemaType would contain LineItem

3. Now that you know the type of error, you will need to know what is the
element /attribute causing the problem. you can retrieve this from the
offendingQName

For the example the OffendingQname would contain Description

4. To see what is expected you can use the list of QNames expectedQNames
(This could be a list instead of an array as it is currently defined) .

For the example the list would contain a list with only one Element -
Quantity

There would be one XMLValidationError generated for each type of error
encountered. In the current scenario often you might see more than error
message being printed out. The best analogy I can give is that every message
is contained in a individual XMLError object. so similarly there will be a
XMLValidationError for each of these objects.

 

There are different kinds of error that can be generated by the validator.
Each of the unique ones will be caputured in a unique errorType( of course
documented)

I realize this is a very simplistic example. I would be interested in
exploring this issue further..for now it would be nice to tackle the problem
one step at a time.

Regards

Dutta:)



Toby H Ferguson <to...@Sun.COM> wrote:

Dutta,

thank you for moving this forward and for your proposal - this is an
important feature lacking in every one of the 9  XML packages I've explored
and yet essential for providing a bridge between XML on the backend and UI
screens on the front.

For me the critical use case is that the user has been asked to enter data
and doesn't know that the underlying validation mechanism is XML - so how
can a program stand between the user and the validation system and translate
for him/her? I tried a couple of examples out using your proposed API and
perhaps I don't understand it properly, but I couldn't see how to get the
information I'd need. 

Firstly, if there're missing attributes or elements it wasn't clear to me
what the XmlValidationError would contain to indicate the missing parts. A
problem I'd had before was getting hold of the relevant schema and instance
entity locations and being able to navigate through them - when stuff is
missing the current structures don't provide much information, and its not
clear how your proposal would handle that case. (Unfortunately its not
sufficient to simply give a file name and line number for the use cases I am
trying to satisfy - I really need to get hold of the underlying problems so
that I can translate them into the domain specific language of the user.)

The "" string - what is this? It wasn't clear to me how that would relate to
the error found - could you explain please. (I'm hoping that this will
somehow lead to the corresponding SchemaType object against which the
validation is incorrect - is there any reason that we can't have this object
itself, rather than having a string which we then have to resolve?)

Another error case I'm working with and thats the identity type errors - how
will XmlValidationError show errors in uniqueness properties, or problems
with keys and keyrefs? I tried exploring the object graph given an XmlError
generated from such a validation mistake but never could connect it back to
the underlying problem - even though I can see a SchemaIdentityConstraint
class (or something like it) in the Javadoc!

I can see how XmlValidationError might provide access to problems with an
enumerated type - but how would it work if there was a problem with a list
type? How could the client get hold of the information about the list such
that the user could be guided on what the problem was? And what about a
Union type - how is that represented?

What would be useful is to have a list of the errors that are going to be
covered by this class - having looked through the XML Beans code I found
lots of obscure errors which I'd never thought of - I'd be curious as to
what your vision was of the errors that this class was going to cover!

Thanks for taking this on, making a proposal and asking for feedback. I am
keen to contribute.

Toby H Ferguson

Dutta Satadip wrote:


 

  _____  



Subject: 
Proposal: To Provide a mechanism to dynamically extract validation errors

From: 
Dutta Satadip  <ma...@sbcglobal.net> <s-...@sbcglobal.net>

Date: 
Sun, 1 Feb 2004 01:31:36 -0800 (PST)

To: 
xmlbeans-dev@xml.apache.org <ma...@xml.apache.org> ,
xmlbeans-users@xml.apache.org <ma...@xml.apache.org> 


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

 

         }

 

 

 



  _____  


- ---------------------------------------------------------------------

To unsubscribe, e-mail:   xmlbeans-user-unsubscribe@xml.apache.org
<ma...@xml.apache.org> 

For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
<ma...@xml.apache.org> 

Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
<http://xml.apache.org/xmlbeans/>