axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <>
Subject Re: [Axis2] Schema parsing
Date Tue, 08 Nov 2005 20:41:53 GMT

I always like the idea of taking a DOM-like object (how about AXIOM) and
making it typed. So instead on doing OMAbstractFactory.createOMElement(),
you could do TOMAbstractFactory.createElement(Schema s);

Then as you navigated the tree, you could query the type of a given element
and set its value using type-specific setters:

if (el.getType()==DOUBLE) el.setDouble(doub);

IBM has published a model a bit like this (SDO -
but I've always found this a little heavy. I may have been overly influenced
by the implementation rather than the interface.

I like the idea of Axis2 building a TOM model (Typed Object Model) which
then uses OM under the covers. Honestly I'm not sucking up... it was the
name that popped into my head.

What do you think?


On 11/8/05, Tom Oinn <> wrote:
> Sanjiva Weerawarana wrote:
> > On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
> >> There is some schema parsing stuff here in the webservices commons:
> >>
> >>
> >>
> >> It sounds like you might be going a step beyond just parsing things
> into
> >> a schema oject model though?
> >
> > Since we're already using the commons schema (above) in Axis2 (for the
> > Axis2 data binding stuff), Tom would you guys be able to contribute to
> > that and help drive that to ultimate success? It doesn't seem to make
> > sense to create a parallel universe.
> Agreed on that, I'll have to take a proper look at the commons schema
> stuff to see whether I agree that that's the right way to go (a very
> brief look suggests it's sane). Basically I can get the QName of the
> type that the operation expects and want some way of getting the
> expected structure of a document conforming to that type to then drive
> my data binding layer. This also involved handling the rather grotty way
> the Definition object handles the various imports. Something like the
> following for usage would be ideal for us :
> Definition def = .... (get Definition here from WSDL4J)
> SchemaDescriber sd = new SchemaDescriber(def)
> ...
> QName operationInputType = ....
> SchemaDescription description = sd.getDescriptionFor(operationInputType)
> and then use 'description' to generate our input ports on the workflow
> processor and the logic required to massage those inputs into the
> request document - obviously similar things apply for outputs.
> Makes sense to drive this off the Definition object as this has already
> done the work of resolving imported schema (albeit badly) and if you're
> running in a WSDL centric world you almost certainly have one lying
> around anyway.
> Cheers,
> Tom

View raw message