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 - http://www-128.ibm.com/developerworks/library/specification/j-commonj-sdowmt/index.html) 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?
Paul
On 11/8/05, Tom Oinn <[EMAIL PROTECTED]> 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:
>>
>> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
>>
>> 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
