wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] V2 Schema and WSDL Issues
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 7 Apr 2005 15:55:56 -0400
I just checked how many definitions
were in the schema just because of starting to use Handle, ID and Key.
It turned out to only be three! I thought it was larger because those where
often the first reason I saw for keeping a definition in the v2 schema.
The RegistrationContext and PortletContext definitions were impacted by
the leasing resolution and these carry into many other definitions.
Rich
Subbu Allamaraju <subbu@bea.com>
04/07/05 11:09 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] V2 Schema and
WSDL Issues |
|
Rich Thompson wrote:
>
> Most of the types that are defined in the latest schema resulted from
> one of two cases (which do not involve real v2 changes):
>
> 1. Switching to using the Handle, ID and Key types rather than string.
> This acknowledges that stacks can now handle these, but impacts many
> core types.
May we should revisit changing these most commonly used inner types. If
we avoid changes to those types, we could improve our reuse.
> 2. The need for any type which includes a changed type to also be
> defined. My testing said that if this was now done, the changes in
> included types would not be reflected.
True. I was referring to the same when I mentioned changing nested types.
Subbu
>
> Rich
>
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 04/07/05 09:35 AM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> Re:
[wsrp] V2 Schema and WSDL Issues
>
>
>
>
>
>
>
>
> >
> > The current draft v2 schema file leverages the v1 types
(no duplicate
> > defines and using extension where possible).
>
> Are we looking at the same XSD? Looking at
> http://www.oasis-open.org/apps/org/workgroup/wsrp/download.php/12078/wsrp_v2_types.xsd,
>
> it has a few types extended, but a number of types are redefined.
For
> example SessionContext? How about PortletDescription?
>
> > I find laudable the goal of a v1 Consumer sending a v1
message to a v2
> > Producer, however, the nature of wsdl requires a match
between the
> > SOAPaction a message targets and a port offered by the
recipient. This
> > requirement would translate into keeping the QNames of
the bound v1
> > operations unchanged as we release v2 (i.e. place them
in the v1
> > bindings namespace). To do so while making signature changes
(we add
> > parameters and fields) would violate, at minimum, wsdl
best practices
> > and likely invalidate a statement in the services section
of the wsdl
> > 1.1 note which allows consumers to make decisions based
on the QName of
> > a portType.
>
> I understand the port SOAPAction issue, and given the nature of SOAP
> stacks, we cannot avoid that.
>
> > I think the more reasonable goal is simplifying how a v2
Producer can
> > offer both v1 and v2 ports. We certainly have been keeping
this as a
> > goal in front us during the work on v2, but should now
review carefully
> > how we cast the v2 wsdl so that the goal is actually realized.
>
> Yes, a Producer should be able to offer both ports in its WSDL. But
once
> it receives a message, it would be easier if a good chunk of the code
> path is shared (provided implementations make some right design
> choices), particulary for some of the more complex V1 operations.
>
> Subbu
>
> >
> > Rich
> >
> >
> > *Subbu Allamaraju <subbu@bea.com>*
> >
> > 04/06/05 10:51 PM
> >
> >
> > To
> >
wsrp <wsrp@lists.oasis-open.org>
> > cc
> >
> > Subject
> >
[wsrp] V2 Schema and WSDL Issues
> >
> >
> >
> >
> >
> >
> >
> >
> > Looking at the draft xsd and wsdl files, I would like to
bring up a few
> > points.
> >
> > The current wsrp_v2_types.xsd redefines all V1 types in
a new V2
> > namespace URI, and then makes modifications to it. On the
positive side,
> > this makes it easy for certain implementations
> >
> > - those that only offer V2
> > - those that would like to maintain separate V1 and V2
implementations
> > with minimal code sharing.
> > - those that use generic programming (such as DOM, SAAJ
etc.).
> >
> > For those implementations that generate types from the
schema (e.g.
> > JAX-RPC), this approach makes type-sharing impossible since
V1 and V2
> > types have no association (e.g. xs:extension). AFAIK, none
of the web
> > service stacks support any namespace mapping between compatible
versions.
> >
> > Another issue is that V1 Consumers cannot send a V1-compliant
message to
> > a V2 Producer, unless the Producer offers V1 port that
accepts a V1
> > message, which goes back to code sharing.
> >
> > Rich - I know you mentioned this earlier, do you still
have a V2 xsd
> > that extends V1 xsd? If required, I can explore this further.
> >
> > On the otherhand, extensions don't completely solve the
problem,
> > particularly when we change deeply nested types (I've examples,
if
> > anyone is interested). So, as long as the additions we
make are
> > immediately under the root of a message, we should be able
to reuse
> > sub-types.
> >
> > Any thoughts?
> >
> > Subbu
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
OASIS TC that
> > generates this mail. You may a link to this group
and all your TCs
> in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your
TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]