Schema Model XSModel based on the Xerces Schema API

[anil.saldhana]

At JBoss, we made the decision to use the Xerces Schema API to represent our Schema Model. An issue we found was that the schema model is more of a flat/read-only model, which when built has no hierarchical information and has lost track of custom prefixes etc.

So approach by JBoss:

1) Parse a schema file into a XSModel.
- Use Xerces Implementation of the XSModel.

2) Construct manually a Schema Model with the hope of adding types/ elements/attributes etc.
- Use JBossXSModel.

Now anytime, you built a Schema Model by parsing from a file, you are stuck. You get the Xerces Impl of XSModel which is read only.

Do not despair. There is a utility class called WSSchemaUtils that has a method called getJBossXSModel as follows:

 public JBossXSModel getJBossXSModel(XSModel)

You can use this utility method to obtain a JBossXSModel from any implementation of XSModel.

This inconvenience is regretted. But I could not help the read only nature of Xerces impl of XSModel. In fact, the Xerces Schema API by itself is a flat read only model.

Another interesting thing about JBossXSModel, is that it can serialize itself into a String. This String can be written to a file or a Stream, after serialization.

[thomas.diesler]

I think, the public API should only be dealing with JBossXSModel which should be an extension to the xerces XSModel.

That JBossXSModel internally uses the xerces schema parser should be an implementation detail.

public JBossXSModel getJBossXSModel(XSModel)

would then be redundant if the clients only ever get passed instances of JBossXSModel.

I don't see a benefit in giving the client the crude XSModel if that is read-only and if JBossXSModel provides a superset of functionality.

[anil.saldhana]

I have had the same thoughts for sometime. I will migrate the XSModel implementation from Xerces team to be engulfed in the JBossXSModel implementation. This will take some time.