RE: Schema validation: getting all the errors

Jason E. Stewart wrote:
> "Forrest Cahoon" <[email protected]> writes:
> 
> > I've been working from the xerces-c examples at 
> > http://xml.apache.org/xerces-c/schema.html#associate but I'm having 
> > trouble converting these to perl.
> 
> Right - sorry that you're having to brave this alone - you are the
> first person to use Xerces-P in this direction so you are uncovering
> bits and pieces of the API that I haven't completely tested - and
> hence, some of it is broken...

Understood.  I really appreciate the help getting this to work.
 
> > $parser->setFeature("$XML::Xerces::XMLUni::fgXercesSchema", 1); 
> > $parser->setProperty(
> >      "XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation",
> >                      $schema);
> 
> Don't you mean:
> 
>   $XML::Xerces::XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation

Yes, I tried that first.  If I don't place that argument in quotes, I
get this error:

Type error in argument 2 of SAX2XMLReader_setProperty, Expected
perl-string. at xerces_test.pl line 15.

When I do use quotes, I get the same error I reported earlier:

Type error in argument 3 of SAX2XMLReader_setProperty. Expected
_p_void at xerce s_test.pl line 15.

> > but that gives me the error
> > 
> > Type error in argument 3 of SAX2XMLReader_setProperty. Expected 
> > _p_void at xerces_test.pl line 15.
> 
> Yes, this is a poor SWIG error, I'm afraid. This is an irritation in
> how Xerces-C defines the setProperty() method - the second argument in
> the C++ function is a void* meaning it can be any value string or
> integer. This shouldn't be an issue - SWIG gives me a way to map from
> acceptable Perl scalar value into what C++ wants.
> 
> The problem is I apperently didn't handle this method properly, so it
> works for things that look like pointers (like integers) but not for
> other things (like strings).
> 
> I'll have to add the proper typemap for this method and make a new snapshot. 
> 
> Thanks for catching this.
> 
> > I've tried many variations on this theme, but nothing seems to work.
> > That's when I decided to try the DOM parser and was able to set the 
> > schema with no problem (using 
> > $parser->setExternalNoNamespaceSchemaLocation).  It's my DOM parser 
> > which dies after it hits the first error.
> 
> There is a way to do this as well. I think the methods you need are:
> 
>   setExitOnFirstFatalError()
>   setValidationConstraintFatal() 
> 
> Set these false and it *should* work... It seems to work fine on
> errors, but fatal errors cause lots of problems.

Hmmm ... it seems that, setting these as you suggest, I'm getting all
the errors when I use the MyErrorHandler cribbed from your code below
as my error handler, but I only get the first error when I use the
standard XML::Xerces::PerlErrorHandler.
 
> I'm including a sample version of the validator for DOM, let me know
> if it helps and I'll include it in the next snapshot.

It looks good to me.

[ ... code snipped ... ]



I'm getting another error which I guess is probably a Xerces-C
problem, but I want to mention it here in case it's got something to
do with Perl.

The documents I'm working on are from the SEC, and can be grabbed from
http://www.sec.gov/info/edgar/rel86rcxmlspec.htm, where the
"Specification Document" is a link to a Windows self-extracting
executable containing sample xml files, and the "Schema files" link
contains the schemas with which to validate them.

They have this line inside a restriction in
ownershipDocumentCommon.xsd.xml:

<xs:pattern value="[0-9A-Za-z #-]*"/>

which causes my validation to die with

Datatype error: Type:InvalidDatatypeValueException, Message:'-' is not
a valid character range; use '\-' instead.

The message is in error, because just like in perl, having a '-' at
the end of a character class means a literal '-'.  I double-checked
the W3C Schema spec and I'm sure this is so.

If I escape the dash with a backslash as the error message suggests,
Xerces is happy.

Forrest Cahoon
not speaking for merrill corporation