axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mukund Balasubramanian <>
Subject Re: XML Schema support for Axis (Contrib from Infravio)
Date Thu, 07 Nov 2002 22:45:41 GMT
Hi Glen,
    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,


Mukund Balasubramanian
Founder and CTO, Infravio.

Glen Daniels wrote:

>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 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.

View raw message