XML Schema capabilities

[anil.saldhana]

JbossWS Tools project depends on XML Schema immensely. There are two subsystems- JavaToWSDL and WSDLToJava.

JavaToWSDL takes in a Service Endpoint Interface(SEI) and generates a WSDL file that can incude one or more XML schema elements. WSDLToJava will read a wsdl document (that includes one or more XML schema elements) and generates a SEI and custom user java classes.

The Xerces Parser for Java has a good schema parsing capability and provides an object model to represent the schema. But this is kind of a read only object graph.

http://xml.apache.org/xerces2-j/javadocs/xs/index.html : XML Schema API
http://xml.apache.org/xerces2-j/javadocs/xerces2 : Xerces 2 Implementation

Now I can create XSD Components like Attributes/types/elements. But there is no root object that represents a schema to which I can add these components.

An ideal situation would be the following:

 XSSchema schema = new XSSchemaImpl(); //THIS IS NOT THERE
 //create a type
 schema.addXSType(xstype);

 //serialize the schema object graph into a file

This is not possible with the xerces implementation because it is schema to Java only and not vice-versa. I think their guess is it is easier to write a schema using the DOM API.

On the other hand, XMLBeans from Apache is a toolkit that can do XML Schema to Java classes. Not vice versa.

[anil.saldhana]

Thanks to Jason Greene for pointing this out to me. There is a Eclipse project going on that provides an object graph to create a schema graph and serialize it into a file.

http://download.eclipse.org/technology/xsd/scripts/home.php

This brings us to a good question:

JavaToWSDL uses the Eclipse API to create schema
WSDLToJava uses the Xerces API to parse the schema for creating Java types.

Does this look like a good solution in the interim?

I prefer Xerces to Eclipse XSD for parsing Schema.

[thomas.diesler]

What you are saying about the missing root element seems unlikely.

The XSLoader cretes instances of XSModel, which should be the root the schema.

XSModel load(org.w3c.dom.ls.LSInput is)

[anil.saldhana]

XSModel is the root when you have a schema file as input. I want to do the reverse. Create a schema file from scratch. Xerces has no facility to SET something on the XSModel

http://xml.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/impl/xs/XSModelImpl.html

Xerces is a pure schema parser alone. It has no facility to create a schema from scratch.

[jason.greene]

It looks like you can construct a model from here:

http://xml.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/impl/xs/SchemaGrammar.html

[anil.saldhana]

Plus an additional thing I noticed is that Xerces Schema Parser wants you to have just one schema element per file. If I have two schema elements, then it throws an error.

No big deal. Can work around this.

[anil.saldhana]

It looks like you can construct a model from here:

http://xml.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/impl/xs/SchemaGrammar.html

Thanks Jason. I am looking at it. But having a simpler API would have been better. I dont understand why they have to make it so complicated.

[anil.saldhana]

Requirements for Eclipse XSD are

http://download.eclipse.org/technology/xsd/scripts/downloads.php

* Please note: As of 2005/04/07 (Build 2.1.0.I200504070700), you will require the Eclipse 3.1 SDK M6 or newer. Earlier Integration builds should run on earlier Eclipse 3.1 builds.
* Please note: Use of XSD requires the EMF Runtime (RT) Package, or the complete SDK.
* Please note: Use of XML Schema (XSD) models with EMF or SDO, requires the XSD Runtime (RT) Package, or the complete SDK.

[anil.saldhana]

Finally I managed to make Xerces schema infrastructure to help me create a test schema object graph as shown by this testcase - test:

/**
 * Test Xerces ability to create XML schema
 * @throws Exception
 */
 public void testSchemaCreation() throws Exception
 {
 String typeNS = "http://org.jboss/types";
 SchemaGrammar sg = new SchemaGrammar(typeNS, new XSDDescription(), new SymbolTable());
 XSComplexTypeDecl ct = new XSComplexTypeDecl();
 ct.setName("HelloObj");
 XSParticleDecl xsp = new XSParticleDecl();
 xsp.fType = XSParticleDecl.PARTICLE_ELEMENT;
 XSElementDecl xsel = new XSElementDecl();
 xsel.fName = "msg";
 xsp.fValue = xsel;

 ct.setValues("msg", typeNS, null, XSConstants.DERIVATION_NONE,
 XSConstants.DERIVATION_NONE, XSConstants.DERIVATION_NONE,
 XSConstants.DERIVATION_NONE, false, null, null, xsp, new XSObjectListImpl(null, 0));

 sg.addGlobalTypeDecl(ct); //Always add global complex types to global types
 //sg.addComplexTypeDecl(ct, new SimpleLocator()); /**THIS DOES NOT WORK**/

 XSModel xsmodel = sg.toXSModel();
 assertNotNull("XSModel is null?", xsmodel);

 XSNamedMap xsnamedmap = xsmodel.getComponentsByNamespace(typedef,typeNS);
 assertNotNull("XSNamedMap is null?", xsnamedmap);
 assertEquals(1, xsnamedmap.getLength());
 assertEquals("HelloObj", xsnamedmap.item(0).getName());
 }

The test run is:

jboss-head/webservice/test] anil% ant -Dtest=org.jboss.test.ws.tools.xmlschema.XercesSchemaParserTestCase one-test


one-test:
 [junit] Running org.jboss.test.ws.tools.xmlschema.XercesSchemaParserTestCase
 [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.913 sec

Not a easy effort, but I hope it was worth it.

[anil.saldhana]

I just found out that the Xerces-2 Implementation is not useful for general use and is subject to change soon.
http://issues.apache.org/jira/browse/XERCESJ-1067

The Xerces Schema API is not going to change.

The Xerces-2 Implementation is good for parsing schema files and building an object model defined by the Xerces Schema API. But if a user wants to use the Xerces-2 implementation to build a schema file (lets say from a Java Interface/Class), it is buggy and inflexible.

So I am at a crossroad. For the WSDL to Java subsystem where schema parsing is required, I am going to use the Xerces-2 implementation. In this case, I am only interested in the Xerces Schema API.

For the Java to WSDL subsystem, where I need to generate the schema files, I will implement the interfaces defined by the Xerces Schema API. This provides me more control in generating the schema files.

Talked to Jason about this and he concurred that this approach seems reasonable.

[thomas.diesler]

It seems that parsing a schema to any object model would require creating instances of that object model and populate the state of those instances. This will probably be done through API methods on those object instances.

Can you show us examples of the actual issues that you are having? Why can't you create a valid schema object tree?

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBWS-234

One caveat that I would like to provide to the Web Service layer that wants to use the schema capabilities provided by tools is the following:

The Web Services layer needs to modify the schema model after it has been written to a file. So tools, when parses the schema file, uses Xerces based implementation, which flattens the schema model. But once the Xerces based XSModel is built, it cannot be modified (like adding new Elements, Attributes etc).

Since the WS layer is requesting access to schema API to be provided so that changes can be made to the schema model, I want to tell that underneath, JBossWS tools has to copy over the Xerces Schema Model "XSModel" into JBoss implementation of XSModel called "JBossXSModelImpl", on which you can do any kind of schema manipulation.

The reason this anomaly exists is because the Xerces implementation is good for parsing schema model from a schema file, but they discourage us from using their implementation to manipulate or create schema model.

On the other hand, there is a util class called "SchemaUtils" that provides a lot of features like schema creation, addition of global elements etc. This util class will be updated to serve the WS layer with JIRA issues like JBWS-234 mentioned above.