I took a look at this property (and its code) and it pretty much works
like I expected, which isn't quite what I'm looking for. If the parser dies
on an attribute, the DOM Node hasn't been created (because
callStarttElement() hasn't been called yet), so using this property doesn't
provide the exact details you would want. It looks like the same thing goes
for errors with the Elements themselves -- I noticed that if I had an error
with an element, this property would return the parent node, not the
offending node (Someone please let me know if I've missed something.) The
other problem with this approach is that it requires that I use the
DOMParser. This feature would be useful with the SAXParser as well.
As far as I can see, there are two ways to do what I want:
(1) Add properties for both the currentElementType and currentAttrName
(this was really easy to implement, if I've done it correctly) to
XMLParser. The drawback is that this doesn't help if you don't have access
to the parser.
(2) Add getCurrentElementType() and getCurrentAttrName() to the LocatorImpl
class (and modify XMLParser accordingly). This still wouldn't solve the
access issue _unless_ the SAXParseException had additional methods (which
I'm no banking on) _or_ there was another reportError() method which threw
a subclass of SAXParseException() which had methods for getting the
CurrentElementType() and CurrentAttrName().
I do realize that I personally could subclass the parsers and mess with the
reportError() method, but I thought this might be useful for everyone else
as well :-). I would appreciate any feedback...
Kito D. Mann
Virtua Communications Corp.
[EMAIL PROTECTED]
Monday February 28, 2000 05:10 PM
Please respond to [EMAIL PROTECTED]; Please respond to
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
[EMAIL PROTECTED]
cc: (bcc: Kito Mann/PSG/Prudential)
Subject: Re: [PROPOSAL] new LocatorImpl methods and/or
SchemaMessageschanges
Getting Nodes when errors occur:
-----------------------------------
Using the DOMParser, another approach is to get the property:
parser.getProperty("http://apache.org/xml/features/dom/current-element-node
");
which will return the current Element Node at the point of error.
You must also:
parser.setFeature("http://apache.org/xml/features/dom/defer-node-expansion";
,
false);
(The DOMParser cannot defer node creation but return random nodes in
error.)
If you wanted to store/take action on all Element Nodes in error, you could
do
so in an
ErrorHandler, and making this call in error, warning and fatalError.
Also you may be interested to keep the parser going on fatalError, so:
parser.setFeature("http://apache.org/xml/features/continue-after-fatal-erro
r",
true);
Have fun,
-Ralf Pfeiffer
Jeffrey Rodriguez wrote:
> Even tough I see how this can be more useful I hate to think about
> the performance implications.
> With the line and column information all we are doing is just
> reporting the scanner information since we are using the
> org.apache.xerces.readers.DefaultEntityHandler getLineNumber()
> and getColumnNumber() methods.
>
> What you are proposing is modifying the implementation of the
> Locator interface ( LocatorImpl) and maybe modifying the
> org.apache.xerces.framework.XMLParser reportError method.
> By the way all the error error reporting originates here at reportError
> method of class XMLParser.
>
> Do you have an implementation?
>
> Thanks,
> Jeffrey Rodriguez
> XML Development
> IBM Cupertino
>
> >From: [EMAIL PROTECTED]
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: [PROPOSAL] new LocatorImpl methods and/or SchemaMessages
changes
> >Date: Fri, 25 Feb 2000 12:37:24 -0500
> >
> >One of the things I need from the schema implementation is details on
> >exactly where an error occurs (over and above the line number). For
> >instance, the message "[Error] :5:66: Incorrect datatype: A is not a
> >boolean." isn't too helpful if I can't access the document via the line
> >number. Basically, what I'd like is the name of the element and (if
> >applicable) the attribute that's causing the problem. As far as I can
> tell,
> >there are two ways to do this: (1) modify the error messages and the
> >methods that call the error reporting methods, and/or (2) modify
> >LocatorImpl() so that it has setElementName(), getElementName(),
> >setAttributeName(), and getAttributeName() methods (and update these
> values
> >accordingly).
> >
> >Does anyone have input on what would be the preference (or if neither of
> >them are appealing)?
> >
> >Kito D. Mann
> >Virtua Communications Corp
> >
> >
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
--
<person name="Ralf I. Pfeiffer"
loc="IBM JTC, Cupertino, CA"
email1="[EMAIL PROTECTED]"
email2="[EMAIL PROTECTED]"
/>
