OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Parse Error Not Thrown When Expected

[ Lists Home | Date Index | Thread Index ]
  • From: Laura Neitzel <laura.neitzel@moai.com>
  • To: "'John Cowan'" <jcowan@reutershealth.com>, Laura Neitzel <laura.neitzel@moai.com>
  • 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@reutershealth.com]
Sent: Tuesday, May 16, 2000 2:30 PM
To: Laura Neitzel
Cc: 'Arnaud Le Hors'; xerces-j-dev@xml.apache.org; xml-dev@xml.org
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@reutershealth.com>
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@xml.org&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@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS