xmlunit-general

[Xmlunit-general] Problems using schema with Validator

[Andy S. <ins...@go...>]

Hi,

I'm having some trouble using org.custommonkey.xmlunit.jaxp13.Validator, and
I'm wondering if it's a limitation of the validator.

I'm trying to validate some FIXML messages I've generated, using the schema
files from fixprotocol.org
(http://fixprotocol.org/specifications/fix4.4fixml).  The schema is split
over various files using includes, but I don't think that's the problem, as
you'll see below.  I locate the main file (that ultimately includes the
rest) using getClass.getResource(), getting the URL's InputStream and
wrapping that in a StreamSource, and adding that to the Validator as the
schema source.  However, on attempting to validate the schema (I've not got
as far as validating the actual XML yet) I get the error message
"Failed to read schema document 'null', because 1) could not find the
document; 2) the document could not be read; 3) the root element of the
document is not <xsd:schema>".

The 'null' I assume is just because I haven't set a specific systemId on the
StreamSource.  However, the xsd file is certainly being found (I've checked
the resource URL and that's fine) and can certainly be read (I've dumped the
InputStream out to the console instead, and see the file's contents).
However, the schema file is using "xs" as its prefix rather than "xsd"
(with corresponding xmlns:xs="http://www.w3.org/2001/XMLSchema") so the root
element is actually <xs:schema> not <xsd:schema>.  So it looks like the
error is due to the 3rd option it gives.

I tried a search & replace within the file to change the prefix being used,
but then it just starts complaining about one of the other files (since they
all use the same prefix).  At least that shows that the xsd:include elements
are working okay...

How rigid is the Validator over the prefix being used, given the namespace
URL itself is correct?  Is the specific prefix hard-coded somewhere, or is
there something I can do to make it check the actual namespace instead?  Or,
since the jaxp13.Validator in v1.3 says it can handle a variety of schema
languages, is this error not being produced by XMLUnit anyway but by
whatever default SchemaFactory it's using?  And if so, is there anything I
can do about it? (e.g. a configuration setting I can pass through to the
SchemaFactory somehow)  Given I didn't produce the schema files, and the
fact there's quite a number of them involved, I'd prefer not to have to go
through and find/replace the prefix in them all...

Oh yes, I forgot to mention, I'm using IBM's 1.6 JDK (in case that has a
bearing on the SchemaFactory that will be present) although I suppose I
could potentially run under any other Windows JDK if that would solve the
problem more easily.

Can anyone help, or at least steer me in the right direction?


Andy

Re: [Xmlunit-general] Problems using schema with Validator

[James A. <jam...@gm...>]

On 16 March 2011 01:42, Andy Stevens <ins...@go...>wrote:

> Hi,
>
> I'm having some trouble using org.custommonkey.xmlunit.jaxp13.Validator,
> and
> I'm wondering if it's a limitation of the validator.
>
> I'm trying to validate some FIXML messages I've generated, using the schema
> files from fixprotocol.org
> (http://fixprotocol.org/specifications/fix4.4fixml).  The schema is split
> over various files using includes, but I don't think that's the problem, as
> you'll see below.  I locate the main file (that ultimately includes the
> rest) using getClass.getResource(), getting the URL's InputStream and
> wrapping that in a StreamSource, and adding that to the Validator as the
> schema source.  However, on attempting to validate the schema (I've not got
> as far as validating the actual XML yet) I get the error message
> "Failed to read schema document 'null', because 1) could not find the
> document; 2) the document could not be read; 3) the root element of the
> document is not <xsd:schema>".
>
> The 'null' I assume is just because I haven't set a specific systemId on
> the
> StreamSource.  However, the xsd file is certainly being found (I've checked
> the resource URL and that's fine) and can certainly be read (I've dumped
> the
> InputStream out to the console instead, and see the file's contents).
> However, the schema file is using "xs" as its prefix rather than "xsd"
> (with corresponding xmlns:xs="http://www.w3.org/2001/XMLSchema") so the
> root
> element is actually <xs:schema> not <xsd:schema>.  So it looks like the
> error is due to the 3rd option it gives.
>
> I tried a search & replace within the file to change the prefix being used,
> but then it just starts complaining about one of the other files (since
> they
> all use the same prefix).  At least that shows that the xsd:include
> elements
> are working okay...
>
> How rigid is the Validator over the prefix being used, given the namespace
> URL itself is correct?  Is the specific prefix hard-coded somewhere, or is
> there something I can do to make it check the actual namespace instead?
>  Or,
> since the jaxp13.Validator in v1.3 says it can handle a variety of schema
> languages, is this error not being produced by XMLUnit anyway but by
> whatever default SchemaFactory it's using?  And if so, is there anything I
> can do about it? (e.g. a configuration setting I can pass through to the
> SchemaFactory somehow)  Given I didn't produce the schema files, and the
> fact there's quite a number of them involved, I'd prefer not to have to go
> through and find/replace the prefix in them all...
>
> Oh yes, I forgot to mention, I'm using IBM's 1.6 JDK (in case that has a
> bearing on the SchemaFactory that will be present) although I suppose I
> could potentially run under any other Windows JDK if that would solve the
> problem more easily.
>
> Can anyone help, or at least steer me in the right direction?
>
>
> Andy
>

Can you provide a stack trace?

A brief inspection of the current svn HEAD hasn't shown that there is any
hard-coded reference to xsd:schema in XMLUnit's source code.

Cheers,

James

Re: [Xmlunit-general] Problems using schema with Validator

[Andy S. <ins...@go...>]

Hi James,

On Wed, 2011-03-16 at 12:37 +0000, James Abley wrote:
> On 16 March 2011 01:42, Andy Stevens <ins...@go...>
> wrote:
>         "Failed to read schema document 'null', because 1) could not
>         find the
>         document; 2) the document could not be read; 3) the root
>         element of the
>         document is not <xsd:schema>".
>         
>         The 'null' I assume is just because I haven't set a specific
>         systemId on the
>         StreamSource.  However, the xsd file is certainly being found
>         (I've checked
>         the resource URL and that's fine) and can certainly be read
>         (I've dumped the
>         InputStream out to the console instead, and see the file's
>         contents).
>         However, the schema file is using "xs" as its prefix rather
>         than "xsd"
>         (with corresponding
>         xmlns:xs="http://www.w3.org/2001/XMLSchema") so the root
>         element is actually <xs:schema> not <xsd:schema>.  So it looks
>         like the
>         error is due to the 3rd option it gives.
...
>         How rigid is the Validator over the prefix being used, given
>         the namespace
>         URL itself is correct?  Is the specific prefix hard-coded
>         somewhere, or is
>         there something I can do to make it check the actual namespace
>         instead?  Or,
>         since the jaxp13.Validator in v1.3 says it can handle a
>         variety of schema
>         languages, is this error not being produced by XMLUnit anyway
>         but by
>         whatever default SchemaFactory it's using?  And if so, is
>         there anything I
>         can do about it? (e.g. a configuration setting I can pass
>         through to the
>         SchemaFactory somehow)  Given I didn't produce the schema
>         files, and the
>         fact there's quite a number of them involved, I'd prefer not
>         to have to go
>         through and find/replace the prefix in them all...
...
> 
> Can you provide a stack trace?
> 
> 
> A brief inspection of the current svn HEAD hasn't shown that there is
> any hard-coded reference to xsd:schema in XMLUnit's source code. 

Sure.  I'd moved on from validating just the schema to try validating a
document instead, but was still seeing the same message in a nested
exception further down the stack trace...

org.custommonkey.xmlunit.exceptions.XMLUnitRuntimeException: Schema is 
invalid
        at 
org.custommonkey.xmlunit.jaxp13.Validator.getInstanceErrors(Validator.java:176)
        at 
fixml.MessageBuilderTest.quickMessageTest(MessageBuilderTest.java:115)
...
Caused by: org.xml.sax.SAXParseException: schema_reference.4: Failed to 
read schema document 'null', because 1) could not find the document; 2) 
the document could not be read; 3) the root element of the document is
not 
<xsd:schema>.
        at 
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown 
Source)
        at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown 
Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
        at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.getSchemaDocument(Unknown 
Source)
        at 
org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown 
Source)
        at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown 
Source)
        at
org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown 
Source)
        at
org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown 
Source)
        at 
org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown 
Source)
        at 
org.custommonkey.xmlunit.jaxp13.Validator.parseSchema(Validator.java:202)
        at 
org.custommonkey.xmlunit.jaxp13.Validator.getInstanceErrors(Validator.java:174)

Based on that, I reckon the message is originally coming from Xerces.
But is there anything (e.g. feature or property) I can pass through to
it via the Validator API that might get it to behave better?


Andy

Re: [Xmlunit-general] Problems using schema with Validator

[Stefan B. <bo...@ap...>]

On 2011-03-16, James Abley wrote:

> A brief inspection of the current svn HEAD hasn't shown that there is any
> hard-coded reference to xsd:schema in XMLUnit's source code.

Be sure to look into
<https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/branches/xmlunit-1.x/>
when searching for the source code.  trunk is where I started XMLUnit
2.x development.

Anyway, there shouldn't be any hard-coded references to xsd in XMLUnit
at all.

<https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/branches/xmlunit-1.x/src/java/org/custommonkey/xmlunit/jaxp13/Validator.java>
doesn't show any.

Stefan

Re: [Xmlunit-general] Problems using schema with Validator

[Stefan B. <bo...@ap...>]

On 2011-03-16, Andy Stevens wrote:

> Or, since the jaxp13.Validator in v1.3 says it can handle a variety of
> schema languages, is this error not being produced by XMLUnit anyway
> but by whatever default SchemaFactory it's using?

I think so.

> And if so, is there anything I can do about it? (e.g. a configuration
> setting I can pass through to the SchemaFactory somehow)

Honestly, I don't know.  If you find some sort of property that would
make your SchemaFactory instance happy, you can use the
Validator-constructor that accepts a SchemaFactory argument and pass in
your fully configured factory.

> Oh yes, I forgot to mention, I'm using IBM's 1.6 JDK (in case that has a
> bearing on the SchemaFactory that will be present) although I suppose I
> could potentially run under any other Windows JDK if that would solve the
> problem more easily.

I've commited a simple testcase that uses "foo" as prefix rather than
"xsd" to XMLUnit's svn tree[1] and it passes on my Windows7 machine
using Oracle's JDK 6 (.23) as well as the OpenJDK7 milestone (not quite
the latest) that I have installed.

Stefan

[1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit?view=revision&revision=491