[oXygen-user] WSDL documentation missing imported files

[Sorin Ristache]

Hello,

The tool for generating HTML documentation for a WSDL definition file is 
more limited than the one for generating documentation for an XML 
Schema. One limitation is that the XML Schema definitions referenced in 
the WSDL file are not documented in the final HTML result. We plan to 
remove this limitation in a future version of Oxygen. It is possible 
that one of the Oxygen versions that will be released before the end of 
this year will implement that. Unfortunately I do not know a tool that 
is able to document also the XML Schema types included in the WSDL file.


Regards,
Sorin


Andrew Clegg wrote:
> Afternoon all,
> 
> I've just started using Oxygen to help with top-down document/literal
> web service development. I'm particularly interested in automatic
> generation of docs from WSDLs and XSDs.
> 
> The WSDL I'm working on lives in a file called Services.wsdl, which
> contains no schema definitions itself. It imports a file called
> MessageTypes.xsd which defines the high-level types corresponding to
> the elements which are immediate children of the wsdl:message
> elements.
> 
> MessageTypes.xsd in turn imports another file, GridTypes.xsd, which
> includes definitions for the fine-grained data types corresponding to
> the actual fields in the input and output messages.
> 
> Now when I use Tools -> Generate Documentation -> WSDL Documentation
> from Services.WSDL to produce HTML documentation, it doesn't seem to
> be aware of the definitions in MessageTypes.xsd (let alone
> GridTypes.xsd). The Type column for each message just says "N/A".
> Ideally I'd like to see the correct type from MessageTypes.xsd in
> here, and have the ability to click through to that type's actual
> definition.
> 
> Am I missing something here? Or does the whole schema really have to
> be stored in the WSDL in order for the doc generator to pick up the
> types correctly? This seems like a pretty serious limitation since
> storing everything in the WSDL is pretty bad practice for non-trivial
> services.
> 
> Anyone know a workaround, or an alternative way to achieve this?
> 
> Cheers,
> 
> Andrew.