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


Title:
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]