Hi,
You should read Paul Norris's answer again:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3013 -- he did
answer your question. It has to do with the difference in how errors and
'normal' events are reported. As XML the two constructs are the same, but in
parsing the order of errors and the other events can (and does) vary.
Chris
-----Original Message-----
From: Benson Cheng [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: Empty tag handling question
Hi Michael,
Thanks for looking into it, I think the part bothers me is Xerces behaves
differently between <Tag2></Tag2> and <Tag2/> when there is validation error on
this tag. Just wondering are they consider the same in XML term (I am not a
XML expert :-)?
thanks,
Benson.
-----Original Message-----
From: Michael Glavassevich [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: Empty tag handling question
Hi Benson,
I had a peek at the SchemaValidator, and all validaton of an empty element
is performed before calling the document handler for the next component in
the pipeline. So any errors will be reported to your ErrorHandler, before
your ContentHandler is notified about the start of the invalid element.
On Tue, 26 Aug 2003, Michael Glavassevich wrote:
> Hi Benson,
>
> What type of error are you refering to?
>
> Reporting document events to your SAX handler occurs at the end of Xerces'
> pipeline, so the parser may report an error before startElement is called
> on your ContentHandler.
>
> On Tue, 26 Aug 2003, Benson Cheng wrote:
>
> > >>
> > Xerces chooses to report them as soon as an error condition has been
> > found.
> > <<
> > But in this case, it seems Xerces found the error before parse the empty
> > tag.
> >
> > Benson.
> >
> > -----Original Message-----
> > From: Michael Glavassevich [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 25, 2003 8:52 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Empty tag handling question
> >
> >
> > On Mon, 25 Aug 2003, Paul Norris wrote:
> >
> > > It might be worth your while putting in a feature request at Bugzilla.
> >
> > > Turning around the timing of events would be very difficult and you're
> >
> > > not likely to get it. But having more information in the
> > > SAXParseException about the context of the error would help you with
> > > deciding where the error belongs is much easier and might get into a
> > > future release.
> > >
> > > Cheers,
> > > Paul.
> >
> > Hi all,
> >
> > I think reliance on error event order is unwise. As far as I can tell,
> > there's nothing that constrains when a parser reports non-fatal errors.
> > Xerces chooses to report them as soon as an error condition has been
> > found. Some other hypothetical parser might decide to buffer all errors
> > it discovers during validation, and then report them later, or emit
> > these events in some other order you weren't hoping for. So even if
> > Xerces changes its behaviour, other parsers may exhibit other behaviour.
> > In short, your SAX code won't be implementation independent.
> >
> > Adding more text in the SAXParseException will not make it easier to
> > programatically determine the context of errors. Besides varying between
> > locales, these messages will vary between parsers. If there's interest
> > by SAX users for this richer form of error reporting, then they should
> > open a feature request for SAX (http://sax.sourceforge.net).
> >
> > If you have a look at the javadocs on the SAX website, it seems that an
> > effort has started to provide more information in SAXParseExceptions
> > (http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#excep
> > tions).
> > The new feature for SAX 2.1(?) would provide URIs with the
> > SAXParseException, that identify the type of error encountered. This
> > doesn't provide the context of the error, but at least it allows a user
> > to programatically determine which constraints were violated, which
> > would be a great improvement over the current behaviour.
> >
> > --------------------
> > Michael Glavassevich
> > [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > 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]
> >
> >
>
>
--
--------------------
Michael Glavassevich
[EMAIL PROTECTED]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
