John,
I agree that Description does not have a targetNamespace since it combines components from potentially many <description> elements. However, getNamespaces() does make sense although it is not strictly part of the component model.
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: [EMAIL PROTECTED]
| John Kaputin <[EMAIL PROTECTED]>
05/24/2006 12:46 PM
|
|
Hi Chathura,
> Can i make a request to add the following two methods to the
> Description component model.
> getTargetNamespace()
> getNamespaces()
The Description interface interface in Woden reflects only the properties
defined for the Description Component in the WSDL 2.0 spec and these do not
include target namespace or declared namespaces. This is because the WSDL
2.0 Component model is an abstract WSDL model that has no notion of
namespaces, because it does not expose document composition and the use of
namespaces to avoid name clashes.
Our initial Woden goal was to develop a Component model API that faithfully
reflects the WSDL 2.0 Component model per Section 2 of the WSDL 2.0 Part 1
spec to validate the spec - that is, confirm that it can be implemented and
that it is useful. I would prefer to keep to that goal at least until the
W3C interop event in July. However any feedback about the usefulness or
deficiencies of the Component model would help the WSDL 2.0 working group
evaluate the Component model. Could you provide some more detail about
what you are trying to achieve and why you need namespace information in
the Component model so we can understand your requirement a bit better.
Thanks.
> I noticed that the getMessageExchangePatten() method in the two models
> are inconsistent.Its getMessageExchangePatten in one and getPattern in
> the other.
This difference is deliberate. In the spec the InterfaceOperation Component
defines the property {message exchange pattern} and this property is
reflected in the Woden Component API by
InterfaceOperation.getMessageExchangePattern() whereas the <wsdl:operation>
element contains the attribute 'pattern' and this attribute is reflected in
the Woden Element API by InterfaceOperationElement.getPattern(). That is,
the Component API faithfully reflects the spec's Component model and the
Element API faithfully reflects the spec's XML representation (in terms of
element and attribute names). At least, that was my starting point. I
guess a usability issue with this design is that you need to be familar
with the spec to understand the mappings between differently named methods
in the two APIs. I still think I prefer a Component API that matches the
Component model and and Element API that matches the XML, but I'd like to
hear more views from others on this topic.
If we were to sync up the method names, then I think we should go with the
Component model names as they are more descriptive. However, although this
would make the mapping between Component API and Element API more
intuitive, it would mean that the mappings between the Element API and the
XML infoset would be less obvious.
regards,
John Kaputin
"Chathura Herath"
<[EMAIL PROTECTED]
com> To
[email protected]
24/05/2006 06:13 cc
Subject
Please respond to Adding two methods to the
[EMAIL PROTECTED] Description Componenet
he.org
Hi,
Can i make a request to add the following two methods to the
Description component model.
getTargetNamespace()
getNamespaces()
Though they are infoset related it will be very useful for the wsdl
processing point of view. I could open a JIRA for this if there is no
reason not to.
Feedback:
I noticed that the getMessageExchangePatten() method in the two models
are inconsistent.Its getMessageExchangePatten in one and getPattern in
the other. I would suggest we rename one to the other for consistency.
Thanks
Chathura
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
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]
