[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][wsia] Draft spec v0.85
Rich, All the Axis related problems you reported are fixed in latest cvs. You can now use "xsd:schema" and the imports should work ok as well. Please open a bugreport on http://nagoya.apache.org/bugzilla as usual if you find any other issues with Apache Axis. Thanks, dims -----Original Message----- From: Rich Thompson [mailto:firstname.lastname@example.org] Sent: Friday, November 22, 2002 10:58 PM To: email@example.com; firstname.lastname@example.org Subject: [wsrp][wsia] Draft spec v0.85 Here is the draft reflecting the decisions from the recent F2F: (See attached file: WSIA - WSRP Interface Specification v0.85.doc) Here are the current versions of the WSDl files ... the Axis tools will not process this unless upgraded to the latest set of bug fixes. The WSDL group continues to work on making this something all the tools can process and produce/receive messages from each other. (See attached file: WSRP_v1_Interfaces.wsdl)(See attached file: WSRP_v1_Binding.wsdl)(See attached file: WSRP_Service.wsdl) In pulling this together I have worked through clarifying a number of areas people questioned, including sections 8.3 & 8.4 discussing interoperability of roles. It currently discusses how Producers and Consumers making different choices about supporting this option. The one area this has left me with big concerns is when both choose to support roles. I don't see any clearly definable semantics whereby Consumer maps its roles to the Producer published roles. To keep it simple, I would like to consider the scenario where: The Consumer only supports the spec defined roles of Administrator, User and Guest The Producer declares the roles Admin, Buyer and Seller A reasonable administrator at the Consumer will probably map the Administrator role to the Producer's Admin role, but clearly the granularity of the Producer's roles does not match the granularity of the Consumer's roles. There is no reasonable mapping available to be made. Reflecting on this further, the whole schema of role mapping only really works when there is a huge overlap in the roles supported at the Producer and the Consumer. To me this is more and more smelling like something that belongs as an extension rather than an inherent part of the spec. The other area I am questioning whether it brings enough value to be included in v1.0 is the registration portType. So much of the function is in the extensions array that I'm starting to wonder if the entire portType should move out of the spec.
Powered by eList eXpress LLC