Re: Woden Design

[Arthur Ryman <ry...@ca.ibm.com>]

Cindy,

BTW, the QName resolution problem goes beyond your case.

I think we should actually change the whole API to use component handles 
instead of component references.

A component handle would contain the QName (or other identifier - this 
varies by component) and an optional component reference (assuming you 
could resolve it).

Using handles has the advantage that you can parse each document 
independently and then combine them in the component model where the 
handles would resolve.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



"Cindy McNally" <ci...@hotmail.com> 
12/17/2006 09:56 AM
Please respond to
woden-dev@ws.apache.org


To
woden-dev@ws.apache.org
cc

Subject
Re: Woden Design






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" <ar...@gmail.com>
>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 <ci...@hotmail.com> 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: woden-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: woden-dev-help@ws.apache.org
>

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered 

by Pandora http://radio.msn.com/?icid=T002MSN03A07001


---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org