Hi Jacob Thanks for the reply
I don't think line numbers will completely solve our problem - although its a good suggestion that we might utilize in other ways. Our issue is that we abstract the document and XML details from users and have "tried" to use only the XMLBeans libraries and generated interfaces in managing ours docs. If we can avoid using the cursor and DOM APIs, we will. I don't understand the purpose of having that field in the error if it does not get populated ... thanks again Les -----Original Message----- From: Jacob Danner [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 12:58 PM To: [email protected] Subject: Re: XmlObject references in XmlError I know you can get line information from the XmlError, will this not work for you? What about getting the XmlCursor using the XmlError.getCursorLocation() or even XmlError.getObjectLocation()? I have had success with those in the past, is there something preventing you from using them? -Jacob Danner On 5/8/07, Les Walker <[EMAIL PROTECTED]> wrote: > > > > > Our application invokes the validate method of XML object and saves > the returned XmlError messages through an XmlOptions instance > containing a collection. We need to be able to report back to the user > a list of invalid nodes and attributes, but it seems the source > XmlObject field in the XmlError is mostly left unset. We can walk the > tree from the bottom up and derive a unique set of invalid elements by > recursively invoking validate, but it seems there should be a better > way to pinpoint the source of error in an instance. > > Is this a bug? intended behavior? any suggestions how this can be > acheived? > > thanks for any and all assistance > > LW --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
