Sorry to get into this thread late, but our perspective (including Vidyanand) on the reason behind most of the design is as follows:
1. Schema processing stages can generally be sequentially described as follows:
XML Schema Document -> Lexical Object Model (DOM) -> Schema Specific Manipulation Model (The library in question) -> Usable Type system (If one exists)
The Library we have proposed here satisfies completely the requirements for Schema Manipulation as well as giving an option for reversing the process from an "XmlSchema" in the object model to an XML Schema document. resolution of names, in this context would fit in from stage 3->4. Towards this end, our Schema processing module is to Schema what WSDL4J is for WSDL - a higher level object heirarchy to validate, serialize and deserialize for a specific XML format.
2. An other big driver for the implementation of this module along the lines that we have is the fact that it is modeeled almost identically on the XmlSchema classes from Microsoft .Net. This is an advantage not only because of ease of migration/porting between platforms but also because problems with the heirarchy would be identified by both the Java as well as the .Net communities.
3. Finally, in terms of the path forward, if popular consensus points at sharing this module/code between projects, we would be open to the idea. Axis and WSIF seem to be obvious alternatives that have been discussed. our specific recommendation towards Axis is not for any reason except familiarity with the Axis codebase which would enable us to contribute more towards the project going forward.
In either case, we are willing to take responsibility for maintenance within the limits of our resource contraints and look forward to contributing towards the community.
Hope this clears up some of the issues,
ThanX,
Mukund Balasubramanian
Founder and CTO, Infravio.
Glen Daniels wrote:
Hi Vidyanand!
1. The QualifiedName is there because after you do aI don't quite see this. It seems to me that (abstractly) a Type lives inside an XmlSchema, which defines schema for a given targetNamespace. Therefore...
XmlSchema.compile(..) all the Types are supposed to be obtained form
XmlSchema.getSchemaTypes(). This would include any types from the schema
that is imported. In this a localname alone is not sufficient. But this
feature viz. compile has not been implemented :-(
* Types don't need to store a QName, they just need an NCNAME and a reference to their containing schema. The same is true for Elements, etc.
* If you call something like getQName() on a type, it can return "new QName(parent.getTargetNamespace(), this.name)". This can be handy in that you can dynamically change the namespace of a schema object without updating all the QNames "inside" it - the information is captured once, where it abstractly lives in the model.
* getSchemaTypes() probably doesn't want to return ALL types that are imported, just the ones actually defined by the schema in question. There should (IMHO) be another API for getting access to the imported types.
2) We haven't considered a schemacontext class. But I would think of theHm, I think a schema which imports other schemas isn't quite the same thing as what I was thinking of for SchemaContext, though there are some API similarities. In particular, WSDL's <types> section can contain three schemas for different namespaces, none of which import each other, but all of which are used by the <message>s later in the WSDL. I guess you could implement this as a new XmlSchema object, except that XmlSchemas should be constrained to need a valid targetNamespace, and can have types/elements/etc added to them - neither of which would be the case for this "virtual" schema container/context.
schema context as being a new schema object with all the other required
schemas being imported( am I right ??? ). If so implementing the compile
method would solve the problem you are trying to address.
3) Yes we could want to contribute this code to apache. But I would notThat sounds great! Let me know what you think of my comments above.
think it should be a totally separate project by itslef till a lot of
things are sorted out.( for eg. the compile method). I had spoken to
Dims about this and he also feels the same. Use it in axis for sometime
and if there is a need and the module is mature enough then we could
think of a different CVS tree And we are also looking forward to see
axis use this schema module :-).
--Glen
