[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]