[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] 1.1 vs. 2.0 planning
I think the distinction Mike proposes is right on - I also think we should not have interface changes from 1.0 to 1.1 unless they really are required to fix something. One thing I think we can consider for 1.1 in addition to the items listed below are markup fragment rules for additional markups, e.g. for phones (WML and VoiceXML), since this would not impact the WSRP interfaces, but only define additional options for markups. Best regards, Thomas |---------+-----------------------------> | | Michael Freedman | | | <Michael.Freedman@| | | oracle.com> | | | | | | 04/16/2003 07:59 | | | PM | | | | |---------+-----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: WSRP <wsrp@lists.oasis-open.org> | | cc: | | Subject: [wsrp] 1.1 vs. 2.0 planning | | | >------------------------------------------------------------------------------------------------------------------------------| I thought it might be useful to begin discussing whether/how to differentiate what goes into 1.1 vs. 2.0 ahead of our May to F2F. To get the discussion started I will reiterate my view which I outlined during our January F2F: Version 1.1 should contain only those enhancements that don't add or alter the 1.0 API. The exception to this rule would be an addition/alteration to fix a bug in the 1.0 specification. The version following 1.1 [Currently called 2.0] becomes the first update where we change/alter the API. At the moment this would mean the focus of 1.1 would not be to added/extend existing function. Rather 1.1 would: clarify the 1.0 specification where deemed necessary define UDDI support [and any other registry we cared about] define carrying markup over Soap with attachements/DIME. clarify interoperability and conformance I think we should limit 1.1 by not altering the protocol/adding new function for the following reasons: 1.1 should follow 1.0 reasonably quickly [Oct-Dec?]. Upgrading API/function so quickly after releasing 1.0 will likely confuse the market and slow adoption. I.e. 1.0 consumers and producers are likely just coming to market during this time period. Our next API/functional release should include changes/function based on real world/customer feedback not just our own ideas/experience. Our likely 1.1 schedule precludes giving consumer/producers enough time to experience WSRP and communicate true priorities for change. Interoperability/Conformance is grunt work compared to defining new function. If both are a focus of a release interoperability/conformance is likely to suffer. -Mike-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]