0

I am trying to verify the correctness of a very large schema. Basically I am doing that using XSOM parser using the following code 

XSOMParser parser = new XSOMParser(); 
parser.setErrorHandler( .. );
parser.parse( IOUtils.toInputStream( xsdAsString ) );
However this does not verify all the errors I have in my schema. I am using Oxygen editor as my xml editor and when I open my schema in the editor, I see lot more and different errors in my schema than what I get from XSOM parser. Does anyone know what the difference is between the two kind of checks? Also, is there a more correct way to verify my schema?
Rush
  • 35
  • 4
  • By 'verify', do you mean that you are trying to confirm that the schema is syntactically correct and obeys all the constraints imposed by the XSD spec? Or that you are trying to confirm that the schema correctly reflects the application domain and accords with the beliefs of domain experts? – C. M. Sperberg-McQueen Feb 05 '15 at 14:10
  • Hi, thanks for replying. What I am trying to do is confirm that the schema is syntactically correct and obeys all the xsd specs. An help would be appreciated. – Rush Feb 05 '15 at 19:06

2 Answers2

1

Without knowing more about XSOM's level of completeness and conformance to the spec than can readily be found on the web site, it's not possible to answer the question "what is the difference between the two kinds of checks?" usefully.

In general, different implementations of the same specification will detect different errors and give different error messages; this general rule also holds true for XSD.

In the case of XSD it is also true that some implementors have found parts of the spec very difficult to understand, so interoperability of implementations is imperfect. Also, some implementations find that they can work just fine with schemas that violate this or that constraint imposed by the specification. Many of the detailed rules in the spec are clearly motivated by very specific notions of how an implementation will work, even though the spec does not admit this and does not document those notions. For implementations that work a different way or use different data structures, checking some of those constraints is pure make-work that contributes nothing to the core functionality of the software; it would not be surprising if some implementors didn't bother to do so, if their goal was to make it possible to do useful work with a schema, as opposed to checking a schema for conformance. (Please note: these are general remarks which may or may not apply to XSOM.)

Oxygen's validation of schemas uses either Saxon or Xerces J (at user option), and in my experience both of these tend to be relatively thorough in checking schemas for conformance issues. Where they disagree on the conformance of a schema, you will have to decide which one has correctly interpreted the specification. Of course, if your goal is to try to maximize your ability to use the schema will different processors, you will edit it until none of the software you test with reports any errors, on the theory that if a widely used processor reports an error but is wrong about the spec, you can either be right about the conformance of your schema to the spec, or have a schema that can be used with that processor.

C. M. Sperberg-McQueen
  • 24,596
  • 5
  • 38
  • 65
-2

There's no way to guarantee your XSD is syntactically correct obeys all XSD rules outside of proprietary tools, which aren't guaranteed themselves.

Seems like what is pushed most often as the "standard" at least in the industry I'm working in.

Gilles Gouaillardet
  • 8,193
  • 11
  • 24
  • 30
Richard Wicks
  • 1