[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]