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