Hi Vidyanand! > 1. The QualifiedName is there because after you do a > 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 :-(
I 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... * 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 the > 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. Hm, 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. > 3) Yes we could want to contribute this code to apache. But I > would not > 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 :-). That sounds great! Let me know what you think of my comments above. --Glen
