[adrian.brock]

I mean we go through a set of rules based on the JDK and JAXP implementation

1) Use JDK5 validation with no validation during the parse
2) Use JAXP implementation specific api with no validation during the parse
3) (Don't) validate during the parse based on a configuration option

[adrian.brock]

"1) Use JDK5 validation with no validation during the parse"

Although looking at the api this is a still two pass operaton?
It looks like this api is more intended for external validation of xml
rather than plugging in an already parsed schema?

[aloubyansky]

1) Use JDK5 validation with no validation during the parse
2) Use JAXP implementation specific api with no validation during the parse
3) (Don't) validate during the parse based on a configuration option

I am not sure I understand you.
If you turn validation off you should not have double XSD parsing issue. I thought we were trying to avoid double parsing with validation on.

[adrian.brock]

I mean we parse the XSD once, then load it into the parser for use during validation,
rather than having JAXP parse/validate the XSD while it is parsing the xml everytime.

Having JAXP parse the XSD everytime is a fallback if the implementation has no support
for pushing XSD models to it.

Whether this can be done using the JDK5 classes, parser implementation classes
or we have to intercept the parse to do the validation ourselves
is something I leave to you. :-)

[adrian.brock]

My initial issue was with the fine grained parsing of annotations take a long time
rather than the validation.

[aloubyansky]

I have just discussed this problem with Sacha who proposed an alternative to writing our own XSD parser based on any SAX parser. Which is to precompile XSDs using Xerces/XsdBinder and save the result in a file. Then, at runtime, an instance of SchemaBinding would be created/deserialized from that precompiled form. What it gives us is:

- removed dependency on Xerces at runtime for projects that use a fixed set of schemas. Dependency on Xerces prevents JEMS projects (JBossCache, jBPM in particular) from using jbossxb and these projects probably would use only one schema that they could precompile and distribute with the binaries;

- potential optimization of creating SchemaBinding at runtime (that was also mentioned by Adrian/Bill in other threads) since schema parsing takes a lot of time.

Of course, in this case, Xerces should still be available at runtime if there are schemas that needs to be parsed from XSD.

Thoughts?

[starksm64]

That sounds fine. The immediate removal of the dependency on the xerces internals from the core of the jbossxb api is immeadiately achieved by this, and this is a key refactoring.

It also opens up the possibility to use other schema languages like relaxng?

[aloubyansky]

The only dependency on Xerces schema API is in one class XsdBinder. Marshalling and unmarshalling are not dependent on Xerces API.

For marshalling though, there is XercesMarshaller that is based on Xerces schema API and used by JBossWS currently. But that one should deprecated and the marshaller that works off of SchemaBinding should be used instead. Both marshallers are tested against the same testsuite so that should not be a big problem.

As to other schemas, there could be RelaxNGBinder, DtdBinder, etc. All that's needed is an instance of SchemaBinding.