[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Parse Error Not Thrown When Expected

• From: Laura Neitzel <laura.neitzel@m...>
• To: "'John Cowan'" <jcowan@r...>, Laura Neitzel <laura.neitzel@m...>
• Date: Tue, 16 May 2000 18:36:20 -0700

John, 
I am creating the object in memory and i am waiting until i see the end of
the container element. Maybe I am using the term "container" too loosely.

Here is an example of a correct doc:
<ncml>
  <Add>
    <Person>
    ....
    </Person>
  </Add> ----> when the documentHandler gets endElement("Add", attList), it
addes the person to the db
  <Add>
    <Car>
    ....
    </Car>
  </Add> ----> when the documentHandler gets endElement("Add", attList), it
addes the car to the db
</ncml>

Here is an incorrect doc:

<ncml>
  <Add>
    <Person>
    ....
    </Person>
    <Car>
    ....
    </Car>
  </Add> -----> the parse error is thrown AFTER the parser forwards the
endElement("Add", attList) event to the documentHandler (thus, after I have
added the Car- the Person gets overwritten by the Car since there are 2
objs).
</ncml>

I guess I could wait until the end of the <ncml>, but we are using this to
do batch loading and may therefore be seeing xml documents with thousands
and thousands of Adds. 
-----Original Message-----
From: John Cowan [mailto:jcowan@r...]
Sent: Tuesday, May 16, 2000 2:30 PM
To: Laura Neitzel
Cc: 'Arnaud Le Hors'; xerces-j-dev@x...; xml-dev@x...
Subject: Re: Parse Error Not Thrown When Expected


Laura Neitzel wrote:

> I'm sorry, i must not have explained the problem well enough. I realize
that
> SAX is event based and I believe that the error HAS occured when it
reaches
> the end of teh element in question (the "Add" element). I just assumed
that
> the parser would perform the validation BEFORE it fires teh event, not
> after.

I'm not clear on when you see the error. Is it when the offending second
element is seen, or when the container element is closed?  Either is a
plausible
implementation strategy.  Expecting an error to be fired *before* the
previous element is ended is probably too much to ask.

A possibility: create the object in memory when you see the initial
endElement, check for validity when you see the container's endElement.

-- 

Schlingt dreifach einen Kreis um dies! || John Cowan
<jcowan@r...>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Follow-Ups:
  • Re: Parse Error Not Thrown When Expected
    • From: Arnaud Le Hors <lehors@u...>
  • Re: Parse Error Not Thrown When Expected
    • From: John Cowan <jcowan@r...>
  • Re: Parse Error Not Thrown When Expected
    • From: "David Brownell" <david-b@p...>

• Prev by Date: Would SAX event handlers be more cooperative?
• Next by Date: Anyone use Lore XML Database from Stanford ?
• Previous by thread: Re: Parse Error Not Thrown When Expected
• Next by thread: Re: Parse Error Not Thrown When Expected
• Index(es):
  • Date
  • Thread