As we discussed on the project phone conference yesterday, we are having fun with schema versions. To summarise 1. component model and API use the IBM-namespaced WSRF specs (the original set), and WS-Addressing of 2003 2. if you pull down the "latest" versions of WSRF & WSN you find out they are inconsisent with each other 3. WSDM has been approved by OASIS, based on draft 0.1 of WSRF and WSN. 3. WSN draft 0.1 uses WSA 2003 for addressing 4. WSDM uses WSA 2004 for addressing, except when using WSN notifications, at which point WSA 2003 has to be used. Apart from different namespaces, the two versions are apparently identical. 5. WSA addressing is still evolving at the W3C. A version may be standardised this year, a version which is likely to be somewhat incompatible with either WSA2003 and 2004. 6. Any attempt to use the latest stuff in the CDDLM component model and deploy API is a painful and futile way to waste days of your life. Stuart, Dejan and myself had a phone discussion with some of the WSDM team yesterday, then Stuart and I discussed what our policy should be. Here it is 1. We will use draft-0.1 of the OASIS versions of WS-RF, WS-N for our WSRF schemas. 2. We will use wsa: to refer to WSA 2003/04 everywhere . Our addresses will be compatible with the draft of WS-N 3. We will declare the wsa2004: alias to the WSA 2004/08 namespace. This will only be used in returning MOWS identity references. 4. We indent to update this stuff when the underlying specifications are standardises. Specifically, once WSA becomes a W3C release, and the WSRF, WSN, WSDM specs are updated to reflect that change, then we will move too. We are not going to chase latest versions of other peoples specs when some of the core underpinnings are still unstable, as it vastly complicates the interoperability story. There will be no attempt to revisit the versions until that point, so people can work with the CDDLM specification knowing that we are not going to update it every month. Note that Apache Hermes/Muse is compatible with our versioning policy. That is, they currently use the same versions we do. I will keep an eye on them to keep them in line. Life would have been easier if WSDM had used the same version of the addressing specification as the rest. Although both Stuart's and my companies voted for WSDM as it stands, we do understand the viewpoint of the few organisations that voted against it on the grounds of unstable foundations. But It has happened; all we can do is manage the implications for us and for people who work with the CDDLM framework. -Steve
Steve Loughran wrote:
Stuart, Dejan and myself had a phone discussion with some of the WSDM team yesterday, then Stuart and I discussed what our policy should be. Here it is
1. We will use draft-0.1 of the OASIS versions of WS-RF, WS-N for our WSRF schemas.
2. We will use wsa: to refer to WSA 2003/04 everywhere . Our addresses will be compatible with the draft of WS-N
3. We will declare the wsa2004: alias to the WSA 2004/08 namespace. This will only be used in returning MOWS identity references.
4. We indent to update this stuff when the underlying specifications are standardises. Specifically, once WSA becomes a W3C release, and the WSRF, WSN, WSDM specs are updated to reflect that change, then we will move too. We are not going to chase latest versions of other peoples specs when some of the core underpinnings are still unstable, as it vastly complicates the interoperability story. There will be no attempt to revisit the versions until that point, so people can work with the CDDLM specification knowing that we are not going to update it every month.
5. We will keep copies of the specifications we use under SCM in the sourceforge project that hosts the schemas. This is the only way to ensure that the specifications will remain available and consistent. It is worth noting that despite the fact that WSDM is based on WSRF 1.2-draft0.1, not all the relevant XSD files are where they need to be for that spec, ws-basefaults has disappeared. By hosting locally we avoid this problem. We do have to patch the XSD/WSDL files so that they import files locally, rather than try and do it from remote (potentially nonexistant) locations. This leads to an interesting problem, the oasis copyright: -------- This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. -------- It is unclear whether fixing the XSD/WSDL files so that they work constitutes "derivative works to assist in implementation" or "a modification". I am requesting clarification on this matter. Sigh. -steve
participants (1)
-
Steve Loughran