Hi Glen abt QualifiedName(). * You are right to some degree that if we do store the reference to their schema then we will need only an NCName. But to me having a QualifiedName that suggests reference is a simpler piece of code than a reference to the Schema. Maintaining references leads to too much of complexity at times. But I do see the value of NCName and referencing the schema object esp in cases where we could change the targetnamespace of a schema in one shot.
abt getSchemaTypes() * For a schema or two that needs to referenced in a WSDL what you say does make sense. But look from a point of view of a person who uses a set of schemas and a schema library. They would want a central place to look at the set of Types available to him. And as to having another API to get to the imported types , it does exist. All we need to do is go through the included/imported schemas and then iterated through the types in it. abt schemacontext() * I do understand the need for something like a SchemaContext. We are not against having a SchemaContext but believe we could mask it behind a XMLSchema itslef. What I was suggesting was that in cases where you have 3 schemas in a WSDL create a 4th schema with probably no targetnamespace . Then add all the other schema objects to the 4th schema as imports. And bingo you have access to all the types in all the 3 schemas. This is another place where I think getSchemaTypes() should return all the types from all schemas. Hope this helps. Once again I want to assure you that we are not against changes in the current architecture. At the end of the day all we want is an XML Schema parsing module that is stable and robust and more importantly is useful. Anyways, I have asked Mukund Balasubramanian, CTO of Infravio, to take a look at this discussion. He will probably shed more light on this pretty soon. Thanks Vidyanand. -----Original Message----- From: Glen Daniels [mailto:gdaniels@;macromedia.com] Sent: Thursday, November 07, 2002 12:00 PM To: '[EMAIL PROTECTED]' Subject: RE: XML Schema support for Axis (Contrib from Infravio) 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
