wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Target for submission of WSRP to OASIS
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Fri, 27 Jun 2003 08:33:59 -0400
Schedule dates (as requested):
Current Delayed
Item
6/27
6/27 Post revised spec (incorporating
errata resolutions)
7/11
8/8 Closing of Kavi vote
to approve revised spec as a Committee Specification
7/14
8/14 Submission of packet requesting
WSRP v1 be considered for approval as an OASIS standard
8/1
9/1 OASIS
TC Admin distributes call to read/comment on WSRP v1 to the OASIS membership
8/15
9/15 OASIS TC Admin opens vote
on promoting WSRP v1 to be an OASIS Standard
9/1
10/1 OASIS membership
vote closes ... any negative votes are referred back to the TC
At this point the WSRP TC responds to
any negative votes based on the accompanying comments. These have ranged
from requesting the OASIS Board approve the spec (e.g. happened recently
when the only negative vote was an objection to companies filing the required
IPR statements) to substantive revisions to the spec that require going
back through a new public review period (i.e. likely a 3-4 month process).
Rich Thompson
| Michael Freedman <Michael.Freedman@oracle.com>
06/26/2003 05:28 PM
|
To:
WSRP <wsrp@lists.oasis-open.org>
cc:
Subject:
Re: [wsrp] Target for submission of
WSRP to OASIS |
Not sure if I can make this call tomorrow so will send
out some questions/comments ahead, just in case.
Also, Rich can you send out a more detailed description of the schedule
using both the current dates and the potential new dates [with the one
month slip]? I.e. rather then just focus on 7/11 vs. 8/11 it is instructive
to see where the end dates are.
My position:
I think there are two independent questions to consider:
a) Have we gained enough experience with WSRP [both implementation and
interoperability] since approving the Technical Committee specification
to satisfy ourselves that what we have is solid and ready for approval?
b) If the answer to (a) is yes, then should we in addition tie the approval
of WSRP to JSR 168's schedule to make sure they exit the change making
period as a unit?
My answer to (a) is yes we are ready. A reasonable amount of successful
interoperability testing has occurred in the past 6 weeks. Moreover, there
doesn't appear to be a mass backlog of new interoperability testing coming
online in July. I think we have achieved a good objective measurement
that being demonstrating real interoperability between different vendors
using 3 different platforms [for both producers and consumers]: .NET, AXIS,
SUN-RI.
My answer to (b) is no we should not tie ourselves to JSR 168's schedule.
Though in practice I think most folks would agree with this [particularly
going forward] the obvious question is what's the harm in doing so now?
Its only a month delay. The practicality is we don't know its
only a month delay. Its only a month delay if JSR 168 doesn't change
[and hence we wasted the month] Though Public review would be schedule
to end in mid-August, changes that occur during this review cycle, [particularly
those entirely unrelated to wsrp] could cause a further review cycle. Furthermore,
unlike the OASIS process, the JSR spec leads/companies have absolute control
over the schedule. We would be tying our schedule not to an open
process but one where 2 companies control the schedule in an environment
where these companies have showed a willingness to manipulate these schedules
for other then technical specification reasons. I.e. the risk of
waiting a month/tieing ourselves to the JSR schedule is [at a minimum]
we lose a month and at a maximum we lose a couple of months. For
me this is a "high" risk given we are 6-9 months late in delivering
our specification. To take this risk I would want to have a reasonable
expectation of reward. I.e. What is the likelihood we will need to
modify WSRP because a problem is found via JSR 168 by early August? I
don't see how the answer to this is any greater/higher then the similar
question I asked myself to answer (a) above -- i.e. What is the likelihood
that waiting another month will allow WSRP implementors/interop testers
to uncover problems we need to fix? Therefore I would assert if we
are comfortable going forward based on (a) we should not delay based on
(b) as our expectations for uncovering problems is no higher.
So, why do I think JSR 168 Public review will not likely impact WSRP? From
a mere read and comment on the specification perspective, portlet function
has been debated/resolved now by two independent though cooperating groups
and we seem to have reached a mutual common model. It is no more
conceivable to me that a 3rd party to this process will enter at the 12th
hour and cause us to tilt the JSR 168 cart then for the same to occur with
WSRP. As we have been in "public review" of WSRP for the
past 6 weeks with neary a wispher from 3rd parties I have similar confidence
for JSR 168.
In addition to a mere specification read, JSR 168 Public review affords
vendors an opportunity to acutally distribute pre-release software in support
of the JSR. It is therefore possible, that vendors will provide such
software on top of WSRP and through the course of actual public use will
uncover issues that need addressing. Though this sounds like an attractive
reason to tie ourselves to JSR 168's schedule the details indicate otherwise.
The basic argument in support of this is we should delay finalizing
WSRP until we have reasonable [real world] experience with its use by independent
parties. Because of the complexity of WSRP, something like JSR 168
[on top of WSRP] is needed to bring portlet development to the masses -
and its only once we get this level of experience can we safely say we
are done. The problem here is that if you believe in this sentiment
a one month delay is too short. Even if available, folks don't acquire,
adopt and develop reasonably complex solutions within a month of a specification
being made public. At best we should expect to install and run the
samples and make basic modifications. This is both due to the practicalities
of dealing with new [alpha] software and the mere fact that the standards
aren't fixed/haven't been approved. For me, such "kicking the
tires" doesn't add significant value to our process of stablizing
and standardizing WSRP.
-Mike-
Rich Thompson wrote:
Late discussion on today's TC call related to when WSRP should be submitted
to OASIS. Issues raised:
- JSR 168 public review plans were delayed from our discussion in May.
- JSR 168 is just now going into public review (expected public visibility
on 7/11 [Sun is closed next week])
- There has been a strong intent of producing aligned WSRP and JSR 168
standards in order to keep the programming models straight forward
- Risk raised is that submitting now would leave reviewing how the alignment
changes during the JSR 168 public review with the OASIS Board. Any comments
they produce would likely start a new 3-month cycle.
- Discussion in May set a target of submitting in July as:
- Several vendor products are interoperating. The number
involved continues to grow (currently at 5).
- Errata emanating from these tests has tended toward clarification
rather than changing things that are broken.
- Any real issues are more likely to occur once the spec
is released and supported by a number of vendors and will have to be fixed
in v1.1 or v2.
Question raised:
Why not delay 1 month to provide greater opportunity to test interoperability
and vet any impacts of issues discovered during the JSR 168 public review?
Please use this email thread to vet opinions on this subject. In addition,
I will schedule an 8 PT, 11ET, 5CET teleconference for tomorrow (6/27)
for those wishing to discuss it verbally. I will also establish a vote
in the Kavi system for this question with a closing date of next Tuesday
(7/1).
Rich Thompson
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]