[Mulgara-dev] RDF/XML parse errors

[Life is hard, and then you die]

On Wed, Oct 29, 2008 at 06:38:30PM -0400, Alex Hall wrote:
> Life is hard, and then you die wrote:
> [snip]
> >>> 1. Change the content handler to log reported errors and continue
> >>> parsing, to match the default Jena behavior.  Only fatal errors will
> >>> cause an exception to be thrown by the content handler.
> >>>
> >>> 2. Make the error handling behavior configurable -- perhaps add an
> >>> option for "strict" or "lax" parsing mode.  The quick-and-dirty way
> >>> would be to use a Java system property, but I don't like that because
> >>> those options tend to get lost over time.  It would be nice to extend
> >>> the MulgaraConfig framework to allow for passing configuration options
> >>> into system components, but I'm not sure I'm willing to bite off that
> >>> task for such a minor change :-)
> >>>
> >>> I prefer option 1, but I'm open to option 2.  Thoughts or suggestions?
> > 
> > I'd prefer option 2. The problem with the logs is that from an
> > application perspective they're not visible, so it looks like
> > everything is fine and you don't notice any problems until somebody
> > goes and analyzes the logs.
> > 
> > However, I do appreciate your point about how to configure this -
> > adding an attribute to the MulgaraConfig is easy enough, but that
> > object is available to anything but the SessionFactoryFactory's.
> 
> Do you mean unavailable?

Yes, sorry.

[snip]
> If there were a way of configuring the content handler using
> MulgaraConfig then I would be much more open to option 2.  But there
> isn't, and I don't have the time to write one, which is why I'm
> leaning towards option 1.

I understand - we're all lazy. :-)

[snip]
> > I don't think the open-world assumption is a reason for saying I'll
> > accept any garbage in my db. For applications that do want that, I
> > would indeed say they can build their own garbage handler :-)
> 
> Let me point out that not throwing exceptions for recoverable errors
> will not cause your db to be filled with "any old garbage".  A
> recoverable error means that the associated resource (i.e. XML
> element) that caused the error will not generate any statements.
> Basically, the parser unwinds the stack back up the document tree
> until a non-error state is reached and continues parsing as normal
> with the next child element.
[snip]

Ok. Then I stand corrected: this is compatible with the open-world
assumption.


  Cheers,

  Ronald