Hi Cindy,

I'm not sure I understand your point. The WSDL 2.0 only talks about
the component model. There is no such thing as the XML model.

In any case, the whole process of resolving XML schema components is
vague. The processor is supposed to use some undefined process for
locating schema components. Even if an xs:import has a schemaLocation,
that is just a hint. There is no requirement to retrieve the schema.

-- Arthur

On 12/17/06, Cindy McNally <[EMAIL PROTECTED]> wrote:
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]



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

Reply via email to