Arthur,
In the case where a Description component represents multiple <description>
elements consisting of a 'root' <description> element and one or more
levels of imported or included <description>s, the properties of that
Description component (Interfaces, Bindings, Services, etc) are drawn from
all of those <description> elements, not just the root element. The
Description component is created by calling toComponent() on the
DescriptionElement representing the root <description> element and the
behaviour is to navigate down the tree of DescriptionElement and
ImportElement or IncludeElement objects to populate the properties of the
Description component object. Note that WSDL <import> and <include> are
not yet implemented in Woden, but this is how I expect it to work.
The toElement() method of the Description component will return a reference
to the DescriptionElement representing the root <description> element from
which the Description component was created. This DescriptionElement can be
used to provide the same information as the Description component's
flattened view (you just have to access it explicitly via the API,
navigating the ImportElement/IncludeElement structure). I don't see any
problem going from a Description component to <description> element,
providing we understand/agree on what that means - e.g. while a Description
will show all WSDL components from an underlying hierarchy of imported WSDL
documents, its corresponding DescriptionElement is just the root
<description> in that hierarchy and the Element model API must be used to
access the same information.
Another aspect of this design is that all <description> elements are
treated the same - i.e. you can call toComponent() on any
DescriptionElement an get a Description component back. So let's say WSDL
A imports WSDL B which contains a <description> element with just a single
<interface> element. 'Normally' you would call toComponent() on the
DescriptionElement representing WSDL A and Interfaces property of the
returned Description component would contain the <interface> from WSDL B.
However, you can also call toComponent() on the DescriptionElement
representing WSDL B, but that Description component would contain just one
Interface component and nothing else. There's probably no reason for doing
that, but unless we treat nested <description> elements differently to the
root <description> element in the Element API, there's probably not way to
avoid it. From my interpretation of Part 2, I don't think this violates
the WSDL 2.0 spec.
John Kaputin
Arthur Ryman
<[EMAIL PROTECTED]
il.com> To
[email protected]
07/11/2005 21:43 cc
Subject
Please respond to Re: Design change for WSDL
woden-dev Description implementation
John,
I just looked at the new design and I have a question. Description is
actually very different from the other components since it respresents one
or more <description> elements. Doesn't this break the assumption you're
making, i.e. that you can go to a <description> element from a Description
component? I general, there are several <description> elements for a
Description component.
On 11/4/05, Lawrence Mandel <[EMAIL PROTECTED]> wrote:
John,
I'm in favour in consolidating the implementation classes wherever it
won't have a negative usability impact (such as when it requires odd or
confusing method names).
As for the documentation you have, I'd encourage you to post what you
have to the Wiki. We can refine it later but at least this will allow
people to take a look at something.
Lawrence
John Kaputin <
[EMAIL PROTECTED]>
To
11/03/2005 04:56 PM [email protected]
cc
Please respond to Subject
woden-dev Design change for WSDL
Description
implementation
I have just committed change r330632 so that now the Description and
DescriptionElement interfaces are implemented by a single class,
DescriptionImpl. Details of the design change, the rationale and a UML
class diagram are in the attached PDF. Comments welcome.
(See attached file: Design for WSDL Description.pdf)
BTW, I have various fragments of design in Word and UML that I still need
to collate into some design documentation on the website or wiki.
John
Kaputin---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
