Cindy,
please see my comments below in response to your posting.

thanks,
John Kaputin


"Cindy McNally" <[EMAIL PROTECTED]> wrote on 12/12/2006 16:38:09:

> A clean separation exists between the WSDL 2.0 xml model and the WSDL 2.0

> component model within the WSDL 2.0 spec. You guys have done a great job
> manifesting this within the Woden architecture.  There are a few places
> within Woden, however, where this separation has become blurred:
>
> 1. WSDLReader impls should not throw an exception if a wsdl:import fails
to
> resolve to a wsdl document when building the xml model.  QName resolution

> should be deferred to the time at which component model is generated,
i.e.
> broken references within the xml model are NOT errors. The WSDL 2.0 spec
> states that the location attribute on a wsdl:import is optional, and if
> present, it is merely a hint.

Woden is not throwing an exception because the wsdl:import fails to
resolve, but because of a bug (thanks for highlighting this). Woden
correctly issues a warning about the import failure (WSDL503,Could not
locate the WSDL document at URL ...), but later on in the code the
resulting null reference is used, causing a null pointer exception. I have
raised JIRA WODEN-118 and will fix this bug for M7. So, Woden does treat
location as a 'hint' in so far as it does not explicitly throw an exception
if the location does not resolve to a document. However, Woden does not yet
adopt any alternative approaches to resolve a wsdl:import.

>
> 2. Schema docs contained within TypesElement are parsed into Schema
> components rather than SchemaElements (which may model a schema language
> other than xml shema.) Schema component generation should be deferred to
> component model generation using a deserializer. Woden's xml schema
> deserializer should be registered within pre-populated extension
registry. A
> Schema component should be a ComponentExtension?

We are aware that while the WSDL 2.0 spec talks specifically about XML
Schema it does allow for other data type systems. Our early work on the
Woden API and implementation was based solely on XML Schema for simplicity
- i.e. we wanted to focus on the WSDL element and component APIs, not on
alternative data type systems. However, we do have a 'todo' about adding
flexibility for other non-XML Schema or non-XML type systems at some point.
We just haven't had the bandwidth to think about it yet and with our
current developer resources we probably won't at least until we have
completed full support for the WSDL component model, WSDL assertions, WSDL
serialization and possibly WSDL 1.1 to 2.0 conversion.

I like your suggestion about using the extension mechanism for parsing XML
schema, rather than placing that parsing logic in the WSDLReader
implementation.  I will raise a JIRA to ensure we don't lose track of this
issue and will add your suggestion to the JIRA comments.

>
> 3. BindingFaultReferenceElement has no Direction attribute, i.e. user has
no
> way of distinguishing between an infault and an outfault element without
> access to component model. Note that the BindingMessageReferenceElement
API
> is correct in this regard.

I replied to this as a comment to JIRA WODEN-117.

>
> By maintaining the separation between component model and xml model,
Woden
> becomes much more flexible, i.e. allowing users to leverage one or the
> other, or both.  This is especially critical in situations where
referenced
> components may be constructed from information other than an XML 1.0
> serialization.

Woden has separate APIs for the WSDL component model and the xml infoset -
the Component API and the Element API. However, the Woden implementation
does not separate these models. They are closely tied, with corresponding
interfaces from the APIs being implemented by a common class (e.g.
InterfaceImpl implements Interface and InterfaceElement). So in Woden, the
two APIs are just different views of the same data.

That's a point in time statement about Woden - as I commented in JIRA
WODEN-117, we have not yet fully considered programmatic creation and
modification of WSDL (i.e. we have focussed mainly on parsing so far as our
focus has been on helping the W3C complete the WSDL 2.0 spec).

Of course, it's possible that someone may provide a different
implementation of the Woden APIs with their own WSDLReader implementation
which separates the component and xml model implementations.

>
> _________________________________________________________________
> Get free, personalized commercial-free online radio with MSN Radio
powered
> by Pandora http://radio.msn.com/?icid=T002MSN03A07001
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to