OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



I think we should not further delay WSRP.

The risk of any changes in the JSR which would break consistency with WSRP
as a result of the public review is very low; IBM would definitively be
strongly opposed to such changes.

The major stake holders are all in the JSR 168 EG and were already
participating in the extended community review.

If nevertheless the unlikely event would occur that somebody actually
proposes a change for JSR 168 which would break the consistency with WSRP,
IBM and very likely many other JSR 168 EG members would vote against such a
change in order to maintain consistency with WSRP.

Best regards,

Thomas

Thomas Schaeck
Architect WebSphere Portal Server, STSM
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479   Mobile: +49-(0)171-6928407   e-mail:
schaeck@de.ibm.com   Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany


|---------+----------------------------->
|         |           Michael Freedman  |
|         |           <Michael.Freedman@|
|         |           oracle.com>       |
|         |                             |
|         |           06/26/2003 11: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]