Hi Arthur,
While I agree it would be OK, I believe it unecessarily complicates the
design. As an example, what happens in cases where the schemaLocation
attribute on an xs:import is null?
References to element decls on input, output and fault elements may not be
resolvable within the xml model, i.e. where, as mentioned within the wsdl
spec, schema components are cached and or cataloged.
As stated in my previous post, a broken qname reference is only an error
within the component model. It is not an error within the xml model:
see: http://www.w3.org/TR/2006/CR-wsdl20-20060327/#qnameres
So, by keeping the component model and xml model separate, you solve the
above problem by deserializing a SchemaImportElement within the xml model
and throwing an exception if, and only if, the user converts the xml model
into a component model.
From: "Arthur Ryman" <[EMAIL PROTECTED]>
Reply-To: woden-dev@ws.apache.org
To: woden-dev@ws.apache.org
Subject: Re: Woden Design
Date: Wed, 13 Dec 2006 21:53:20 -0500
Cindy,
Thx for the comments.
Note that the WSDL 2.0 component model does not have Schema
components. It does have ElementDeclaration and TypeDefinition
components which COULD come from XML Schema, but other type systems
are theorectically allowed. Therefore I think that creating Schema
components is OK since they are not part of the WSDL 2.0 component
model.
On 12/12/06, Cindy McNally <[EMAIL PROTECTED]> wrote:
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.
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?
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.
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.
_________________________________________________________________
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]
_________________________________________________________________
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]
